This has been always confusing me. Here is a statement which states "Principle of least privilege" whereas one more statement states, use UIPI to protect applications from low integrity level processes.
As an application I may not do any privileged operations, but in order to protect my UI (using UIPI), I will be forced to promote my application to high integrity.
Contradicting. Any one has a better explanation for this?
I am aware of the difference between those. I am not looking for what are these. I am looking at how to balance between these.
For example,
I am developing an application, I am not doing any privileged operation, so my application can run in low integrity level itself. So as per principle of least privilege, I am happy to execute my application as low integrity level. But if i run my application with low integrity level, i am prone to attacks by UIPI. Anyone can send messages and cause DOS attack. This makes me think, shall i go ahead and launch my application as high integrity so that no other medium integrity apps can attack my application. But this goes against "Principle of least privilege"
Mandatory Integrity Control was added in Vista and has 6 major integrity levels but only 3 of them are used for normal user processes; Low, Medium and High.
Win32 processes run at medium integrity level by default (when started from Explorer etc.) so most Win32 apps are already protected from low integrity level processes (UWP apps, Edge, IE and Chrome).
UIPI inspects the sender and receivers integrity levels and allows the interaction if sender >= receiver. There are some exceptions. Signed UIAccess applications in system directories have special access and you can manually add exceptions in your application for specific messages if desired.
You can view a processes integrity level with Process Explorer.
Applications running at medium IL are trusted from the users point of view, you should not worry about protecting yourself from them. High IL applications are trusted by the user/administrator and the machine. You should not run at high IL unless you need those additional rights that come with it. Low IL is for high risk applications like web browsers and PDF readers.
This is not documented anywhere but the current implementation allows you to create your own levels, so you could run your application with a integrity level somewhere between low and medium.
Related
It appears that cross process messages are allowed in Windows, and while Windows appears to have protection so that a lower process can't inject a message to a higher process, say they are at the same level at the time and a message is created with an invalid pointer that gets updated. Isn't that a potential issue? For one, crashing apps or corrupting data, or two, maybe exploiting an app that may elevate later?
TIA!!
Cross process security risks are all about using the enhanced privileges of other processes to do something that your process cannot do. Privilege isolation of the message system protects against that.
crashing apps or corrupting data
Processes can terminate other processes at the same privilege level. Being able to send messages to other processes at the same privilege level adds nothing new.
exploiting an app that may elevate later
Processes cannot elevate later. Elevation happens as part of process creation.
AFAIK, OS X is a BSD derivation, which doesn't have actual mandatory file locking. If so, it seems that I have no way to prevent writing access from other programs even while I am writing a file.
How to guarantee file integrity in such environment? I don't care integrity after my program exited, because that's now user's responsibility. But at least, I think I need some kind of guarantee while my program is running.
How do other programs guarantee file content integrity without mandatory locking? Especially database programs. If there's common technique or recommended practice, please let me know.
Update
I am looking for this for data layer of GUI application for non-engineer users. And currently, my program have this situations.
Data is too big that it cannot be fit to RAM. And even hard to be temporarily copied. So it cannot be read/written atomically, and should be used from disk directly while program is running.
A long running professional GUI content editor application used by humans who are non-engineers. Though users are not engineers, but they still can access the file simultaneously with Finder or another programs. So users can delete or write on currently using file accidentally. Problem is users don't understand what is actually happening, and expect program handles file integrity at least program is running.
I think the only way to guarantee file's integrity in current situation is,
Open file with system-wide exclusive mandatory lock. Now the file is program's responsibility.
Check for integrity.
Use the file as like external memory while program is running.
Write all the modifications.
Unlock. Now the file is user's responsibility.
Because OS X lacks system-wide mandatory lock, so now I don't know what to do for this. But still I believe there's a way to archive this kind of file integrity, which just I don't know. And I want to know how everybody else handles this.
This question is not about my programming error. That's another problem. Current problem is protecting data from another programs which doesn't respect advisory file lockings. And also, users are usually root and the program is running with same user, so trivial Unix file privilege is not useful.
You have to look at the problem that you are trying to actually solve with mandatory locking.
File content integrity is not guaranteed by mandatory locking; unless you keep your file locked 24/7; file integrity will still depend on all processes observing file format/access conventions (and can still fail due to hard drive errors etc.).
What mandatory locking protects you against is programming errors that (by accident, not out of malice) fail to respect the proper locking protocols. At the same time, that protection is only partial, since failure to acquire a lock (mandatory or not) can still lead to file corruption. Mandatory locking can also reduce possible concurrency more than needed. In short, mandatory locking provides more protection than advisory locking against software defects, but the protection is not complete.
One solution to the problem of accidental corruption is to use a library that is aggressively tested for preserving data integrity. One such library (there are others) is SQlite (see also here and here for more information). On OS X, Core Data provides an abstraction layer over SQLite as a data storage. Obviously, such an approach should be complemented by replication/backup so that you have protection against other causes for data corruption where the storage layer cannot help you (media failure, accidental deletion).
Additional protection can be gained by restricting file access to a database and allowing access only through a gateway (such as a socket or messaging library). Then you will just have a single process running that merely acquires a lock (and never releases it). This setup is fairly easy to test; the lock is merely to prevent having more than one instance of the gateway process running.
One simple solution would be to simply hide the file from the user until your program is done using it.
There are various ways to hide files. It depends on whether you're modifying an existing file that was previously visible to the user or creating a new file. Even if modifying an existing file, it might be best to create a hidden working copy and then atomically exchange its contents with the file that's visible to the user.
One approach to hiding a file is to create it in a location which is not normally visible to users. (That is, it's not necessary that the file be totally impossible for the user to reach, just out of the way so that they won't stumble on it.) You can obtain such a location using -[NSFileManager URLForDirectory:inDomain:appropriateForURL:create:error:] and passing NSItemReplacementDirectory and NSUserDomainMask for the first two parameters. See -replaceItemAtURL:withItemAtURL:backupItemName:options:resultingItemURL:error: method for how to atomically move the file into its file place.
You can set a file to be hidden using various APIs. You can use -[NSURL setResourceValue:forKey:error:] with the key NSURLIsHiddenKey. You can use the chflags() system call to set UF_HIDDEN. The old Unix standby is to use a filename starting with a period ('.').
Here's some details about this topic:
https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileCoordinators/FileCoordinators.html
Now I think the basic policy on OSX is something like this.
Always allow access by any process.
Always be prepared for shared data file mutation.
Be notified when other processes mutates the file content, and provide proper response on them. For example you can display an error to end users if other process is trying to access the file. And then users will learn that's bad, and will not do it again.
Is there any way to grant access to network shares to Low Mandatory Level processes (UAC)?
Further explanation:
To migrate some third-party library security issues we are considering setting Integrity Mode to isolating process to Low, but we do need to have process read/write freely from specified single file system share (UNC path, possibly on separate computer).
Does anyone know is there a way to do this?
Thanks
Yes this is available by default. Integrity of a process only affects local security not remote security. This can be proven by creating a low integrity version of notepad -
Copy C:\windows\system32\notepad.exe to a location i.e.
C:\test\lownote.exe
Run icacls C:\test\lownote.exe /setintegritylevel Low
Run lownote
Confirm with Process Explorer (http://live.sysinternals.com/procexp.exe) it is running as low integrity. Note you can open files on HDD but can't save to them,
except in low integrity sections of user profile Browse to network,
path using UNC share - you can open/save files fine.
That being said you may come across access denied messages when using a low integrity process to write to network shares. This cause can be found by using procmon on the computer running your app http://live.sysinternals.com/ProcMon.exe and filtering to include Result is "ACCESS DENIED" and Process Name is - the name of your process.
What will not available is drive mappings...you will see an "access denied" thrown when trying to read HKCU[location of drive letter]
As per MSDN documentation:
However, you can use other types of communication between a low-integrity process and a higher-integrity process. The types of communication that you can use include:
Clipboard (copy and paste)
Remote procedure call (RPC)
Sockets
Window messages that the higher-integrity process has been explicitly
allowed to receive from lower-integrity processes by calling
ChangeWindowMessageFilter
Shared memory, where the higher-integrity
process explicitly lowers the mandatory label on the shared memory
section ( Important This is particularly dangerous, and the
higher-integrity process must be careful to validate all data that is
written to the shared section.)
COM interfaces, where the launch
activation rights are set programmatically by the higher-integrity
process to allow binding from low integrity clients
Named pipes,
where the creator explicitly sets the mandatory label on the pipe to allow access to lower-integrity processes
ref http://msdn.microsoft.com/en-us/library/bb625960.aspx
What consideration should we have (both software and hardware) when we build a soft-realtime application on windows : a task that occurs every XXX milliseconds and that should be completed within YYY milliseconds. (Altough consequences of missing a deadline are bad, the application can still recover from missed deadline - hence the "soft" realtime).
A few questions that already comes to my mind:
Are there registry settings that should be changed, looked at?
Is it better to use external graphic card instead of onboard video?
Example expected answer:
You should read on (and disable) Nagle Algorithm if you use TCP as it can delay packet sending.
(This could maybe be turned in community wiki)
Consider using Multimedia Class Scheduler Service
From the doc
The Multimedia Class Scheduler service (MMCSS) enables multimedia
applications to ensure that their time-sensitive processing receives
prioritized access to CPU resources. This service enables multimedia
applications to utilize as much of the CPU as possible without denying
CPU resources to lower-priority applications
Another option availale to you is to adjust your thread priorities but you need to be very careful not to get to aggressive with this.
Hardware-wise, will this be running on server-class equipment? If so, the usual steps apply. Disable hyperthreading, turbo boost, and CPU C-states. Implement some level of CPU-affinity on your critical processes.
I maintain a variety of managed userlabs on a university campus. These machines all currently run Windows XP and we have a windows service that is used to "lock" a machine by blocking any keyboard or mouse input. The locking happens during our scripted OS installation so that users aren't able to accidentally halt or break the process. It is also used to prevent users from logging into machines until they are checked out at the front desk of a given lab. Ctrl+Alt+Del is blocked via a keyboard filter driver and the rest of the keys and mouse are currently blocked using the BlockInput() function from user32.dll.
In XP, the service runs as Local System and the checkbox for "Allow service to interact with desktop" must be enabled from the BlockInput() call to succeed. Under Vista, this no longer works I'm guessing because of the Session 0 isolation changes. The call succeeds, but input is not actually blocked.
The keyboard filter driver still works just fine and we can use that to block the whole keyboard instead of just Ctrl+Alt+Del. But I'm at a loss as to how we're going to block the mouse now. I'm not even entirely sure the Session 0 isolation is to blame.
Can anyone recommend a fix or a workaround to allow us to block mouse input from a service in Vista and beyond? I've looked for alternative win32 API's without luck. Assuming Session 0 isolation is to blame, is there a legitimate way to call the function from Session 1 or would that sort of defeat the purpose of the isolation? Will I have to rely on an elevated companion exe that runs on user login and communicates with the service?
From a service, you can use WTSEnumerateSessions to get all logged on user sessions, WTSQueryUserToken to get the logged on user's token, and then use CreateProcessAsUser with that token to get code running on the user's desktop. This has the disadvantage that the code will run as the logged on user. Since all input is disabled, this is probably safe enough and is at least as safe as the existing XP solution.]
EDIT: BlockInput requires a high mandatory integrity level. You could try adding this group to the token, but then you have code with higher privileges running on the desktop and potentially open to attacks.
An alternative might be to use your service just to disable all HID class devices on the machine.