Tell if the process is running in a Guest account
in [Win32 API]
|
From: nki00 on 26 Jun 2010 04:42 "Jackie" <Jackie(a)an.on> wrote in message news:4c24a168$0$18692$c3e8da3(a)news.astraweb.com... > nki00 wrote: >> Man, I need to read up on those security APIs instead of blindly >> following >> what you write for me:) >> > > There's of course always the chance that I or anyone else here gives you > false information, so it may be a good idea. I'll try to give you sources > though. :D > I have dealt with similar things before because it has tickled my > curiosity, so I don't know everything. I often need to look something up > on MSDN as well. :) > > -- > Regards, > Jackie Thanks. You were very helpful again. I guess, it does make sense -- if a process is started as an admin from a guest account it is not running as a guest anymore. (This bahavior is a bit different under XP, since elevation of privileges is not available.)
From: Jackie on 26 Jun 2010 05:46 nki00 wrote: > Thanks. You were very helpful again. > > I guess, it does make sense -- if a process is started as an admin from a > guest account it is not running as a guest anymore. (This bahavior is a bit > different under XP, since elevation of privileges is not available.) Thank you. :) It appears like it, at least, since guests should not be able to make any system changes. Personally, if I could, I would disable the possibility to elevate completely on that account. I would assume MSDN has a page which explains the changes from XP to Vista. The problem is just where to look, I guess. Hmm.. I wonder if one could use GetTokenInformation with TokenOrigin. And maybe TokenLogonSid with that token. Would be interesting to know if that would work. Not sure if that would be good design. http://msdn.microsoft.com/en-us/library/aa446671%28VS.85%29.aspx http://msdn.microsoft.com/en-us/library/aa379626%28VS.85%29.aspx -- Regards, Jackie
From: nki00 on 28 Jun 2010 14:49 > It appears like it, at least, since guests should not be able to make any > system changes. Personally, if I could, I would disable the possibility to > elevate completely on that account. > I would assume MSDN has a page which explains the changes from XP to > Vista. The problem is just where to look, I guess. > Hmm.. I wonder if one could use GetTokenInformation with TokenOrigin. And > maybe TokenLogonSid with that token. Would be interesting to know if that > would work. Not sure if that would be good design. > > http://msdn.microsoft.com/en-us/library/aa446671%28VS.85%29.aspx > http://msdn.microsoft.com/en-us/library/aa379626%28VS.85%29.aspx > > -- > Regards, > Jackie Yes, my whole idea behind this was to disable certain features in case of a Guest account, but it appears that once someone runs my process as an admin there's really no distinction. As for the TokenOrigin, it returns the LUID, which I'm not sure what I should do with. It also may be NULL in some cases according to documentation. I'll try to play around with those values though...
From: Jackie on 28 Jun 2010 18:47 > Yes, my whole idea behind this was to disable certain features in case of a > Guest account, but it appears that once someone runs my process as an admin > there's really no distinction. I was thinking that the system should disable that by default so that guests can't do local or remote logons. Maybe you can do it yourself but I am afraid I can't help you much with that. > As for the TokenOrigin, it returns the LUID, which I'm not sure what I > should do with. It also may be NULL in some cases according to > documentation. I'll try to play around with those values though... Played a bit with this right now. The value from TokenOrigin seems to be 999 here while the actual session ID is 1. From MSDN: > "If the token resulted from a logon that used explicit credentials, such as passing a name, domain, and password to the LogonUser function, then the TOKEN_ORIGIN structure will contain the ID of the logon session that created it." Guessing that's not what's happening because the ID is not right. > "If the token resulted from network authentication, such as a call to AcceptSecurityContext or a call to LogonUser with dwLogonType set to LOGON32_LOGON_NETWORK or LOGON32_LOGON_NETWORK_CLEARTEXT, then this value will be zero. Certainly not this. > "Windows XP/2000: This value is not supported." Then I guess this method is out of the question whether it can be used or not. TokenLinkedToken can be used to get the elevated token, and maybe the other way around as well (I have only used the first). Can't be used either though since it's not the guest account that is actually elevated (I assume). Hmm.. Actually.. We can't do anything useful with the token because that's the one we get from OpenProcessToken. Sorry to have you read all that. I hope you plan on changing privileges or something for the guest account so that it's impossible for someone to gain access just from reverse engineering your application and removing the limitations in it. I think all I can do from now on is mostly speculating. I kind of feel that one shouldn't need to do this though. -- Regards, Jackie
From: Jackie on 28 Jun 2010 18:53
I found this but I think you'll have the same problem: http://www.installsetupconfig.com/win32programming/accesscontrollistaclexample3_4.html I think the system should deny/allow access to things rather than your application checking whether an account is a member of the Guests group. Just saying, in case you were thinking about doing this. Like I mentioned in my last post. I need to get some sleep now so I'll check back later. -- Regards, Jackie |