From: John Beckett 

Thanks - that's cleared up several issues, and I take your point that
running the Internet Explorer process as a user while having other desktop
processes running as an admin is not really secure.

However, I'm still curious about one thing.

I think that running iexplore.exe as Basic User is using SaferCreateLevel()
to set level SAFER_LEVELID_NORMALUSER. The Sysinternals procexp shows the
restricted iexplore process has having only the privilege
SeChangeNotifyPrivilege (rather than all the admin privileges of other
processes) - good.

Procexp also shows for the iexplore process:
    Group: BUILTIN\Administrators
    Flags: Deny, Owner
(and several other groups (e.g. Everyone) with flag "Mandatory").

You suggest that the Deny flag might be the SE_GROUP_USE_FOR_DENY_ONLY
attribute. However, how would that explain the results of my experiment:

File A.txt has permissions (complete list):
  Administrators - allow Read & Execute, Read.
  Authenticated Users - same.

File B.txt has permissions (complete list):
  Administrators - allow Read & Execute, Read.

Using the restricted iexplore to open these files:
  A.txt - ok (file is displayed in Notepad).
  B.txt - "access is denied" from Notepad.

Other processes on the same desktop can display A.txt and B.txt.

John


"Rich"  wrote in message news::
>    You can adjust your token and run any process to run with the modified
token.  It may or may not make you safer.  In the case of IE, it is running
on your desktop/window station and these are a security boundry.  Your
limited token IE process can still exchange messages with non-token
adjusted processes. This is why Vista has UIPI to go with LUA.
>
>    I believe the deny to which you refer is the SE_GROUP_USE_FOR_DENY_ONLY
attribute.  The reason for this is that some ACL may deny access to members
of a group.  If you could remove that SID from your token you could bypass
that denial.  For this reason what happens is that the SID gets marked as
deny only. When evaluating an ACL the SID is not considered for access
grants but is considered for denials.
>
> Rich
>   "John Beckett"
 wrote in message
news:vmq3c21dr7ffm67p6rhv1au3cedsu4db0c{at}4ax.com...
>   "Rich"  wrote in message news::
>   > One reason for privileges to be disabled by default is so that an
>   > application can not unintentionally exploit a privilege.
>
>   Ahh! So, for example, if I write a program that backs up some files, if
>   that is all the program does, then it will only backup files for which the
>   user has Read permission.
>
>   If the program was intended to backup access-denied files, then the
>   program would have to first enable the backup right (which the user would
>   need to have been granted).
>
>   > Beyond enabling and disabling, there is a mechanism to remove
>   > privileges from a token.
>
>   As it happens, it was studying the article on DropMyRights by Michael
>   Howard ("Browsing the Web and Reading E-mail Safely as an
Administrator")
>   that re-kindled my interest in this topic.
>
>   According to ProcExp (Sysinternals Process Explorer), I can log on as an
>   administrator, yet run Internet Explorer as a user (I used the
>   DropMyRights article to set a Software Restriction Policy to run
>   iexplore.exe with Basic User security level).
>
>   ProcExp shows the iexplore.exe process, including Security Properties:
>       Group: BUILTIN\Administrators
>       Flags: Deny, Owner
>
>   I tried to work out exactly what this meant (studying MSDN + Google).
>
>   I gather that the Owner flag indicates that if this process creates an
>   object, then the owner of that object will be set to the SID for
>   BUILTIN\Administrators.
>
>   I haven't work out exactly what the Deny flag means. It seems to me that
>   it must be different from the "mechanism to remove privileges from a
>   token" that you mention (browsing MSDN suggests that you may be referring
>   to calling AdjustTokenPrivileges with NewState = SE_PRIVILEGE_REMOVED,
>   which I gather physically removes the privilege from the token, in which
>   case ProcExp couldn't list it).
>
>   Experiment shows that a file that allows Read permission to Administrators
>   and Authenticated Users _can_ be read by the restricted iexplore.
>
>   However, a file that allows Read permission only to Administrators
>   _cannot_ be read by the restricted iexplore.
>
>   My guess is that the "Deny" flag in the security token for the
>   Administrators SID means that an attempt to access an object by a process
>   will fail, if the attempt relies on matching the Administrators SID in the
>   object's DACL. However, if the DACL contains an ACE allowing access to
>   some other SID in the token, then the access is allowed.
>
>   Have I got this roughly right?
>
>   > I describe this as defense in depth and not anything stronger because
>   > it may not be difficult to work around if the exploited process can get
>   > another process to do its dirty work for it.  It can't use a new child
>   > process as that will inherit the same token but it may be able to
>   > use one already running.
>
>   Interesting. One technique I guess would be a shatter attack, and since
>   the system is pretty complex, no doubt some more.
>
>   Thanks,
>   John

--- BBBS/NT v4.01 Flag-5