The requirement is to be able to run a kiosk application on Windows 10 which has unrestricted capability on the host computer to make arbitrary system calls and launch any kind of app including Appx and Win32. The kiosk app can be fully trusted - it may be thought of as a side-loaded in-house app for machines equipped with conventional keyboard and mouse to be used in a public setting. The user should not be able to circumvent or escape the kiosk app.
Assigned access fits the general idea, except that assigned access only works for Appx which are not full trust (no access to the needed APIs to launch Win32 apps, etc.). These restrictions appear to be by design, so it would be unlikely this approach could successfully meet the stated requirements. Although it is possible to author a WPF app as a "full trust" Appx, it won't work in kiosk mode.
Replacing the Windows shell with a custom one (the kiosk app) would work except that some of the tasks the kiosk app needs to be able to perform require the presence of the explorer shell (e.g. launch an Appx - requires services provided by the explorer shell).
Running a Win32 app above the lock screen might be a solution, if it were possible (I believe this is what assigned access does with its Appx).
Running an app in any normal fashion would require that many hotkey combinations are disabled or intercepted, including [CTRL][Alt][Del], which seems to be a major issue/challenge. It seems there is no way to prevent the user from invoking task manager or otherwise circumventing an app to gain unsecured/unmediated access to the system.
Is there any way to meet the requirement as I've outlined? If so, what is the technique and (if relevant), what APIs are central to the approach?
Update:
Although the full-trust converted WPF AppX could be installed and selected for assigned access, it "did not work" because of some issues found to have been recorded in the event log, specifically: Applications and Services Logs > Microsoft > Windows > Apps > Microsoft-Windows-TWinUI/Operational. Observed behavior was that upon user login, a blue screen would be displayed with the familiar Windows spinner, which would flicker every second or so as if something was being retried over and over. The associated event log messages (all source "Apps") are:
ActivateApplicationForContractByAppIdAsUserWithHost of the app LockDownSample_y1sem70fxfdf6!LockDownSample for the Windows.Launch contract failed with This app does not support the contract specified or is not installed.. (Event ID: 5985)
The app LockDownSample_y1sem70fxfdf6!LockDownSample is not registered for the Windows.Launch contract or is not installed. (Event ID: 5951)
The app Microsoft.WindowsMaps_8wekyb3d8bbwe!App is not registered for the Windows.PreInstalledConfigTask contract or is not installed. (also Event ID: 5951)
Activation via contract helper of the app Microsoft.WindowsMaps_8wekyb3d8bbwe!App for the Windows.PreInstalledConfigTask contract failed with Class not registered. (Event ID: 5990)
Is this due to an intentionally imposed limitation, or is this something which can be resolved?
Update 2:
Found this recent question:
Windows 10 assigned access app fails to start due to not registered for Windows.Launch contract
This fairly accurately describes my experience with Assigned Access for a full-trust kiosk app, concluding with the answer "not yet supported".
Related
Using the Desktop Bridge (formerly known as Project Centennial) through the DAC, one can create a full-trust UWP App. I thought this meant you can now create a Full-Trust UWP App and if so, how do you do that?
What I am trying to figure out is what configuration can I manually set on my UWP Project to grant it full-trust.
If you need some background, I need to create an Enterprise tool that has to be UWP. The application is going to be run on my company and one of the features that would make the UX better is to be able to access some parts of the file system outside of those allowed by UWP and preferably without the summoning of a dialog. Being able to run other DLL would also be a big plus; perhaps DLL Hell is desired this time around.
#Anzurio - just stumbled across your question and thought I'd share our experiences building the new Windows Terminal.
We originally set out to create the Terminal as a UWP app, with a nice modern XAML UI, but quickly found that the UWP app platform couldn't support a couple of our key requirements:
1. Terminal must be able to be launched elevated
2. Terminal must be able to launch & connect to arbitrary executables (e.g. cmd, powershell, wsl, etc.)
Because of these limitations, we had to create the Terminal as a standard Win32 process which contains a XAML Island which hosts the Terminal's Tab Bar and Terminal XAML Control instances in the main window frame.
We have taken care to keep as much app lifetime/logic code OUT of the Win32 host as we can, so that we'll have less work to do if/when the app platform does support our requirements and we get to ship a real UWP Terminal apps.
We are working with the app plat team to figure out how we might be able to build/full-trust modern apps more cleanly in the future.
In the meantime, I hope this response helps, and hope the Terminal source gives you some inspiration as to how to craft your own apps.
I don't know such of options. Yes, DAC can contain the Full-Trusted Win32 apps, but it is only applicable for Win32. UWP - WinRT - apps are restricted with App Container.
The alternative option is - using the "Special capabilities".
Special and restricted capabilities
There are many of declarations that overcome the restrictions of sandbox. Some of these are not applicable for store submission - only for in-house deployment apps. Others need registration for Microsoft to deploy with store. If your requirement is matched, you can use it.
(Added - June 2017) From Win10 AU, we can use the "FullTrustLauncher" API to launch the Win32 component from UWP App. But, yes, it does not mean we can run the "UWP" - WinRT process with full-trust rights. It's applicable only for Win32 process. And, the Win32 app executable should be contained in the application's AppX package and the manifest should declare the executable as "windows.fullTrustProcess".
<Extensions>
<desktop:Extension Category="windows.fullTrustProcess" Executable="fulltrustprocess.exe">
<desktop:FullTrustProcess>
<desktop:ParameterGroup GroupId="SyncGroup" Parameters="/Sync"/>
<desktop:ParameterGroup GroupId="OtherGroup" Parameters="/Other"/>
</desktop:FullTrustProcess>
</desktop:Extension>
</Extensions>
FullTrustProcessLauncher Class
So basically what my trivial research on debuggers lead me to was a debugger works by creating a wrapper around the original process and the process runs within the wrapper.(Not in the scenario where debugger is attached to an already running process). So how does it work for metro apps? Metro apps can only run inside the app container which is allocated to them when they are installed ( actually metro apps are not installed in the true sense) and the mapping between app container and metro app is recorded in a registry key. (All from my research,dont know how correct please correct me if I am wrong). So does the debugger also run within the same app container?
EDIT: A short note on the driving force why I wanted to learn this. I am stuck with this. So I was thinking if I can achieve this IPC by making the desktop app as a debugger (Or automating the debugger, drats this is getting even more creepier) and simulating the communication between metro apps and desktop apps using DebugBreak(From inside the metro app) and Continue statements(From the pseudo debugger app)
The mental image of a "wrapper" is wrong. A debugger is just a separate process that uses the built-in Windows support for debugging. It has the SE_DEBUG privilege and is initiated by an app that has the normal desktop app privileges. Like Visual Studio. So it doesn't run inside the AppContainer itself.
Han's answer is correct. For Metro style apps, we introduced a new feature that allows you to start the app suspended and we will launch the registered debugger with command line options to indicate what process to attach to. See the IPackageDebugSettings API for information on this feature, or check out the http://winrt.codeplex.com project for an example usage. I'm not certain, but there may be developer license restrictions around this API.
As to your original intention of supporting IPC between a Metro style app and a desktop app - as the linked thread states, this is unsupported.
I need to write an application that can detect if the "Bing - Get me there" application is installed on the current phone and if so, launch it.
Is this possible? The app would need to do this for other external applications as well, so a generic method or interface for this would be helpful.
Applications run in a sandbox on Windows Phone and there is no way to tell if other applications are installed unless you are writing both of them and you use a method to announce to other applications that you are installed and they know how to read that announcement.
2 approaches to such announcements would be:
Have both (all) apps synchronise with a web server and report which devices they have been installed on. The apps can the query which other apps have been installed on that device.
Have all apps write a file to a location where all apps can access. The only place to do this is the PicturesLibrary so you have to embed the identifier in the name of the image or in its contents and be able to query all images to identify the other installed apps. The user could manually delete any images you create in this way though.
Beware, neither method can tell if the other app has subsequently been uninstalled though so this is far from foolproof.
As far as I know, there's no way to do that.
Applications on Windows Phone run in complete isolation, and can not act with other applications, other than some highly specialized apps (i.e. for playing media).
I have installed cc.net 1.4.3 version on Windows Vista. But It keeps giving me Interactive services dialog detection when I execute tests. I even have disabled the interactive services from services panel. but still getting this.
Any idea how to get rid of this problem
regards
Sam
No easy fix that you can do. The service is trying to pop up UI on the user desktop. In XP this worked because services and the first user log on both run in session 0. In Vista, services run in session 0 and the first user runs in session 1, so there is no way for a service to directly show UI to the user. This was due to security issues - search for Win32 Shatter Attack to get more details, but basically an untrusted user could send malformed window messages to the services, and in some cases could even cause arbitrary code execution.
You can disable it altogether by disabling the "Interactive Services Detection" service on the system. But you won't see notifications at all, and this will disable it for all interactive services. Best approach is to complain to the vendor to update their software for Vista.
EDIT: And the software is broken on XP when multiple users are logged on and the active user isn't in session 0.
Does anyone have a good guide to capabilities of Windows Services under XP? In particular, I am trying to find out what happens when a program being run as a service tries to open windows, but hasn't been given permission to interact with the desktop.
Basically, I have a program that is/was a GUI application, that should be able to run as a service for long term background processing. Rewriting the program to not display the GUI elements when doing background processing is a major effort, so I'd like to see if there is just a way to ignore the UI elements. It is sort of working now, as long as too many windows aren't opened. I'm trying to figure out what limits I might be running into. Ideally, there would be an MSDN page that discusses this, but I've had no luck finding one yet.
Generally, services should be designed to not have any visible UI. The entire point of a service is to run in the background, without UI, unattended. (Think SQL Server, IIS, etc.)
In most scenarios, a separate application controls the service's operation, should a GUI be needed. (Continuing the samples I just mentioned, SQL Server Management Studio, IIS Manager, etc.) These separate applications configure and manipulate the service (and occasionally, if needed, bounce said service).
If your service requires occasional UI, and said UI can't be isolated to a control app, then you probably should reconsider the fact that you're using a service to begin with. Perhaps a UI application which resides in the system notification area is the right pattern to use? (E.G., Windows Live Communicator.)
A service in Microsoft Windows is a program that runs whenever the computer is running the operating system. It does not require a user to be logged on. Services are needed to perform user-independent tasks such as directory replication, process monitoring, or services to other machines on a network, such as support for the Internet HTTP protocol
Usually it is implemented as a console application that runs in the background and performs tasks that don't require user interaction.
The installed services can be configured through the Services applet, available from
Control Panel --> Administrative Tools in Windows 2000/XP.
Services can be configured to start automatically when operating system starts, so you dont have to start each of them manually after a system reboot.
Creating a Simple Service - MSDN Article
Writing Windows Services Made easy - Code Project Article
Five Steps to Writing Windows Services in C - DevX Article
If you should be thinking of eventually migrating to a newer OS such as Vista or Server 2008, you will find that you cannot give a service permission to interact with the desktop at all. Therefore, from the point of view of forwards compatibility, you should design your service to not require it.
A service in Windows XP can interact with the Desktop if its "Allow Service to Interact with Desktop" property (MMC -> service properties -> Log On tab) is checked. It is also possible to do so by doing the following:
hWinstation = OpenWindowStation("winsta0", FALSE, MAXIMUM_ALLOWED);
SetProcessWindowStation(hWinstation);
hDesktop = OpenDesktop("default", 0, FALSE, MAXIMUM_ALLOWED);
SetThreadDesktop(hDesk);
But be aware that presenting UI from a service process in Windows XP will almost always lead to a security problem (see Shatter attack). You should try to break out the UI part of your application from the service.
Usually the service won't have permission to write to the window station and desktop, so it will fail; even running applications that load user32.dll can fail simply because user32 has initialization code that wants to talk to the window station and can't get access to it unless the service is running as an administrator.