I have 2 processes. One of them is running under admin account, second - under user account with no permissions to admin processes. They need to see each other and compare the path, from where this processes where executed. But first (user) process can't get the path of the second process. Getting path using CreateToolhelp32Snapshot -> OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION) -> QueryFullProcessImageName is not applicable because it works in Vista, Win7 and higher, and I need solution for lower versions of Win.
So, how can I give permissions for user process to see the path of admin process, or how can I share privileges of admin process for the user using Access Tokens or using SetNamedSecurityInfo ?
using delphi desirable.
You can alter this, yes (*) - but you really should reconsider your logic. For example, admin process can open shared MMF with predefined name and store any information you need. You can share this MMF to any user or group you want (you should consider giving read-only access only). This is much safer than opening entire process to out world.
(*) In admin process: OpenProcess, get token and security descriptor, modify DACL to include new right for the desired user account or group, set token/SD back.
Related
This questions is a followup to
Why is SeCreateSymbolicLinkPrivilege ignored on Windows 8?
Given:
The user is in the Administrators group
Turning off UAC is not an option for me.
Running elevated is not an option.
Question: Is it possible to add the SeCreateSymbolicLinkPrivilege to the Standard User Token created by Windows for an admin user?
Appendix
Non elevated admin user:
C:\dayforce\SharpTop>whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== ========
SeShutdownPrivilege Shut down the system Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
C:\dayforce\SharpTop>
A regular user:
C:\Windows\system32>whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============================= ==================================== ========
SeShutdownPrivilege Shut down the system Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
SeCreateSymbolicLinkPrivilege Create symbolic links Disabled
C:\Windows\system32>
Notice a regular user has the SeCreateSymbolicLinkPrivilege privilege, because I have enabled it in the Security Policy. But the admin user is screwed, because doing so does not affect its Standard User Token!
(this is a nonanswer to the actually-asked question, but it is an attempt at an answer for what I perceive to be the actual goal)
I feel your pain -- I've been looking for a way to permit an admin user running nonelevated to create Symbolic Links, without success ...
I've investigated altering the process token (of "explorer" perhaps)
to add the SeCreateSymbolicLinkPrivilege privilege, but it appears
that there is no way to alter the privilege set of an existing token.
Even if your patch process runs as SYSTEM and/or has the
SeTcbPrivilege privilege.
I've investigated using CreateRestrictedToken to create your "own"
nonelevated process, but with the SeCreateSymbolicLinkPrivilege
privilege left enabled. But all anecdotes I've read about
CreateRestrictedToken suggests that the resulting token cannot be
made sufficiently similar to an "authentic" nonelevated token. There
were insurmountable issues with the integrity level, or with the elevated flag
associated with the token.
No matter what users you assign to the create-symlink user right in
security policy manager, if your process runs nonelevated (from a
user with admin), the SeCreateSymbolicLinkPrivilege privilege gets
removed. This happens even if the only user added is "Everyone".
Microsoft really fouled us up on this one, there appears to be no good workaround. There is a possibly hackish solution though ...
Now for the hackish solution - during logon of the user, start a background program (elevated) which will create symlinks on behalf of other processes. This will need to use some sort of IPC, perhaps named pipes, to receive create-symlink-requests from the client process. It's ugly, and probably slow, but other than running Elevated (or disabling UAC), or removing the user from the Administrators group, I don't see any other way.
(Skip to the bottom for the TLDR version.)
OK - so I have searched (really!) and all other UAC articles I have found seem to center on enabling, disabling, detecting or hiding UAC. My issue is not one of those, so here goes:
My user used to have the standard dual-token setup where I was in the Administrators group and the UAC's Consent UI would just ask me if I wanted to proceed. Now, we have separate administrative-level accounts that we need to use, and I have to authenticate with this new user. The problem I am having is that previously, starting an app as Administrator just elevated my current user, where now if I use the credentials of the new administrative user, whatever I am running runs AS that new user.
As an example, previously elevating CMD and typing whoami into the command prompt used to return my normal/current user, where it now returns the new administrative user.
This has serious negative consequences - since this is a new user, and an Administrative-level one, if any files are created using this new user, my normal user cannot write to or delete them unless I manually adjust permissions and ownership. If I use my development environment under the new account (e.g. I need to debug a service or work with a driver) and rebuild something, I end up with a bunch of files that I cannot manipulate unless I am an administrator. Likewise if I add a file while running as this new account - my SCM tool will not be able to update that file later unless it also runs under this new administrative account.
Also, Since a profile is associated with this user, things run under a completely different environment (different %USERNAME%, %USERPROFILE%, %LOCALAPPDATA%, etc.)
Installing an application will also work incorrectly if it is installed just for the current user (e.g. the "Just Me" option), instead of for all users. Things that are licensed to/in my normal user account also fail to function if run under the new account, because things are running as that new user.
The ripple effects of this change are getting larger and larger the more I work with it. So...
[TLDR] Is there a way to get temporary elevation of the current user without that user having the normal dual-token setup you get from being in the Administrative group? Or are you stuck with the impersonation behavior?
AFAIK when I set up my Azure roles I have only one way to specify how much priviledges the process running role code will have - by using <Runtime executionContext> XML tag.
However this looks coarse grained. If I specify "elevated" my code runs under "Local system" which is unlimited priviledges and if I specify "limited" my code runs under some low priviledges user that doesn't have priviledges my code needs.
Is there some convenient way to run Azure role code under some custom user that has limited priviledges that I myself would control?
Right now, your code will already run as a limited user. In fact, there are no users on the VM - it is using a SID injection technique to get a security context at all. From your question, it seems like you need more than a normal user, but less than an admin?
If you really want to have different permissions, you need to create some users (use Startup tasks and net add or DirectoryServices) and set permissions. All of this is scriptable.
The more challenging part comes now to run your code as that user. For this, you need to do what is called impersonation. Your more privileged code (an admin process typically) can obtain a token for a local user and use that to impersonate a user. The code then runs as the user and is restricted. Impersonation is a well covered topic in .NET and other languages.
If you want a clever example of running code as another user, check this post by David Aiken:
http://www.davidaiken.com/2011/01/19/running-azure-startup-tasks-as-a-real-user/
I've got an important resource folder (that can not be embeded in exe file) and I want to limit access of all Windows users except Admin Group ones. My program runs in normal (not Admin) user and I want give resource folder access only to this process. I can ask Admin user's password once, but I don't know is it possible or not?
You can start an elevated rights process from you application, do whatever is needed with admin rights and end it after.
Take a look here: http://victorhurdugaci.com/using-uac-with-c-part-1/
Is there a simple, quick, non-invasive windows admin task that can be performed from a java process to validate if the current process is running as administrator?
I know we could run batch commands to check if current user is member of administrator group. But there are complications of portability across Vista etc.
A simple example would be:
echo. 2> %SYSTEMROOT%\EmptyFile.txt
However, this is invasive. We dont want to create files
Any other option?
In general, you may find it a better choice to check for a specific permission rather than implying permissions from role assignments. One reason for this is that in a domain environment you may have local administrators and domain administrators. They are not necessarily equivalent. Also, even an administrator's permissions can be altered or specific file/directory permissions be "tweaked" to, for example, deny access to "localmachine\administrators".
Checking for a specific permission guarantees that, given specific user credentials, that user can or cannot perform some action, regardless of what roles they might be assigned to.
I know that doesn't answer your question, but it may help shed some light on the problem of assuming permissions from roles.