SBIE and the Drop Rights option - does it work?

So there was a thread in which we were discussing how the DropRights feature of SBIE works. I had tested it in different ways a year or so ago. It was brought up that it did not work in the manner I thought it did. I insisted it did, and performed a test to make sure, and as I expected it was as I thought.

But being the person I am with a nerdmentat, I decided to see if I was right or it was an anomoly, as the other person said he tested it and found different results.

So just because we are adventurous souls here, and we as a cumulative body are fairly well versed in our security applications, lets see what you might find in your own tests.

The following was performed on XP Pro SP2+.

Files tested were to modify c:\boot.ini, modify c:\windows\system32\eula.txt and to create a file in c:\program files\common files\ using notepad.exe

So, start notepad.exe in following methods and results of the 3 tests.

As Admin - no SBIE - all files are modified
As User - no SBIE - denies boot.ini opening, eula.txt is read only, cannot create file in prog files
As Admin, using SRP - no SBIE - same as above

As Admin - in SBIE - no DR - all files are modified
As User - in SBIE - no DR - all files are modified
As SRP - in SBIE - no DR - same as above

As Admin - in SBIE - yes DR - boot.ini denied - prog files allowed - eula.txt allowed
As User - in SBIE - yes DR - same as above
As SRP - in SBIE - yes DR - same as above

So it appears that objects in c: which have default restrictions are upheld in SBIE with the DR option enabled, yet you can install to prog files or modify items in windir that a stripped token should not be allowed to.

It is also interesting to note that if you open boot.ini in SBIE without the DR option enabled, then you enable the DR option, you can still modify boot.ini. If you delete the contents of the box and the virtualized boot.ini file is not present, then you will get denied access.

In the past I have tried to install applications to prog files in a forced folder with SRP also on that folder, and with the DR option enabled, the installation failed. I don't fully understand in this case what the DR option is really doing.

What do you find?

Sul.

 

I tested using XP Home SP3, And I emptied the sandbox in between tests to avoid virtual files.

Here's my results of those same tests,
"modify c:\boot.ini, modify c:\windows\system32\eula.txt and to create a file in c:\program files\common files\ using notepad.exe"

As Admin - no SBIE - All allowed
As User - no SBIE - I could open boot.ini but couldn't modify it, Could not modify eula.txt, Could not create a file in c:\program files\common files\
As Admin, using SRP - no SBIE - I could open boot.ini but couldn't modify it, Could not modify eula.txt, Could not create a file in c:\program files\common files\

As Admin - in SBIE - no DR - All allowed
As User - in SBIE - no DR - All allowed
As SRP - in SBIE - no DR - All allowed

As Admin - in SBIE - yes DR - All allowed
As User - in SBIE - yes DR - All allowed
As SRP - in SBIE - yes DR - All allowed

Looks like we get the same results except for boot.ini, I'm able to open boot.ini I just can't modify it,
My boot.ini file is read-only if I try to change that with non-admin permisions I get an access denied message, if I change that with admin permissions then try to edit the file with non-admin permissions windows still won't let me.

I've had a program fail in the past with drop rights in sandboxie checked, But for me the install told me I needed to be in an admin account to install which I was at the time, So I figured the installer just checked if it had an admin token/permissions which it didn't.

 

1/ Yes, it DOES work.
2/ You are testing this in a completely wrong way.

If anything wants to modify a file outside of sandbox, it's copied over to the sandbox and the modifications are done there - unless you've allowed direct access to that file. You are free to modify stuff how you wish there, since it doesn't affect the real system in any way.

See, this is just notepad.exe being totally stupid. It can't save anything to files that have +R attribute set. Has nothing to do w/ sandboxie.

So, back to the question here: simple and proper way to test this is something like:

Example 1:
Under an account with admin rights, enable drop rights, add cmd.exe to forced programs, reload sandbox configuration, start cmd.exe, and try something like:

Code:

runas /user:Administrator cmd.exe

Now, it asks you for admin credential, you input them correctly, and guess what - it will fail - because admin/power user rights have been stripped from your security credentials.

Example 2:
Repeat your broken test after you have allowed direct access to boot.ini, %WINDIR% or whatever else that LUA has no rights to write to. You'll be denied write there with drop rights (to the real stuff outside of sandbox).

 

Something is just not right here.

Notepad should be a fine tool to test with. As I am sure you are aware, the rights and restrictions placed on objects/containers during OS install apply to not a specific application, but to a user or group. Providing a file has the flags set to allow creation/modification/deletion, it works just fine.

After another round of testing, the DR feature in SBIE does block objects in the root from being modified, either with notepad or cmd. You cannot access/rename/delete/etc either boot.ini nor ntdetect.com. And yes, the flags are cleared to allow it to happen.

Without the DR flag enabled, you can do what you please with them, of course the changes apply to the sandbox only, and it was performed from an admin account.

So it appears for now, until I further test it tonight hopefully, that the DR option does two different things. On one hand it strips the token of admin, and applies those to objects in the root, just as it is done outside the sandbox. Yet on the other hand, areas such as windows and program files this stripped token does not effect within the sandbox, only if you are using a sandboxed thread and directly accessing objects outside of the sandbox.

Not that I am complaining. I love this tool and now wish to know more of why it is doing this.

Sul.

EDIT: this was a newly created sandbox with default settings, it was not told to allow or block anything that is not default. both boot.ini and ntdetect.com have no specific rule in the sandbox.ini file.

 

Well, no, notepad is NOT fine to test with readonly/hidden/system files since it won't let you save those no matter what, even if you have every permission to do it. Why? Because oh it's stupid application coming from DOS times where these DOS attributes have been the only "protection" for files on FAT. So, pick something else than boot.ini or ntdetect.com for your notepad.exe testing since those are RAHS by default and you won't get any meaningful result with notepad.

No. Once again, please - your conclusions are based on notepad idiocy with handling readonly etc. files. Either create normal files with permissions suitable for testing somewhere and test with that or clear all attributes but archive one if you insist on notepad.exe as testing tool. You've selected the most unfortunate objects and tools for your testing that draw you to very wrong conclusions.

 

As far as I understand it the only thing the drop rights does is change the token of the process, http://www.sandboxie.com/phpbb/viewtopic.php?p=29552#29552
nothing else which is why if you look at some of the posts at the sandboxie forum Tzuk couldn't understand why people were so interested in it and after awhile he didn't care to discuss it anymore because it wasn't that interesting, http://www.sandboxie.com/phpbb/viewtopic.php?p=30985#30985


@Sully - I'm just not sure why I'm getting different results than you, It looks like because for me with non-admin permissions I'm able to open the files just not modify them, But you don't seem to be able to even open the file,
Since for you it looks like the file can't even be read sandboxie doesn't get a chance to create a virtual one that allows modifying.

Still unless I'm misunderstanding something, It worked as I expected it to, I was still able to edit the file with sandboxie like I expected since it becomes a virtual file instead of the real file so the drop rights makes no difference,

And I was able to edit the file fine with an admin account but not a non-admin account.
It being a hidden/system file made no difference on me modifying it from an admin account.

I mentioned that one in the other thread, Opened a direct access to C:\Windows\ and tried to save a file there, It worked as expected, I got an access denied message.

 

Let me start by saying that I definately not the type of person who thinks they know it all and shuns others insights. In fact, I will be quite pleased if you do indeed have points here that I can learn from. But I don't quite agree yet with all that you state, and of course I will tell you why. Please feel free, or anyone, to correct me, I will humbly admit it if needed.

The flags for the attributes of a file do not apply if they are not set. I stated, the flags were removed. Notepad is a simple text editor. You can use word, you can use scite, you can use command prompt. It does not matter. It is true that if the flags are set, then a simplistic application like notepad could fail to save etc because the flag is set to make it do so.

You perhaps are assuming that I am not aware of what an attribute on an object is. The tools and objects I chose are exactly what is needed to test in these instances. Creating an object/container after OS install is not what the goal is, nor should it be.

The default security template is applied when you install the OS. In it are listed the permissions for objects and containers. There are two basic .inf files you can examine to see these in practice: defltwk.inf and setup security.inf

For example, in the defltwk.inf you will see objects very specifically given rights, as noted here. You see, the files I chose to work with, boot.ini and ntdetect.com are given permissions from installation time. I chose these files knowing what the permissions were. Discard any attributes, because I understand and have removed them for testing purposes.

Code:

;---------------------------------------------------------------------------------------
;x86 Boot Files
;---------------------------------------------------------------------------------------
"%BootDrive%\boot.ini",2,"D:P(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"
"%BootDrive%\ntdetect.com",2,"D:P(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"
"%BootDrive%\ntldr",2,"D:P(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"
"%BootDrive%\ntbootdd.sys",2,"D:P(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"
"%BootDrive%\autoexec.bat",2,"D:P(A;;GRGX;;;BU)(A;;GRGWGXSD;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"
"%BootDrive%\config.sys",2,"D:P(A;;GRGX;;;BU)(A;;GRGWGXSD;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"

and here are the same values from setup security.inf (which is a security template)

Code:

1="c:\autoexec.bat", 2, "D:P(A;;GRGX;;;BU)(A;;GRGWGXSD;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"
2="c:\boot.ini", 2, "D:P(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"
3="c:\config.sys", 2, "D:P(A;;GRGX;;;BU)(A;;GRGWGXSD;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"
4="c:\documents and settings", 1, "D:AR"
5="c:\documents and settings\all users\application data\microsoft\user account pictures\guest.bmp", 0, "D:(A;;GW;;;AU)(A;OIIONP;GA;;;CO)"
6="c:\ntbootdd.sys", 2, "D:P(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"
7="c:\ntdetect.com", 2, "D:P(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"
8="c:\ntldr", 2, "D:P(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"

and you also have the containers permissions, as well as objects. Container permissions are also explicitly state as shown below.
This is from defltwk.inf

Code:

;---------------------------------------------------------------------------------------------
;System Root (Typically \WINDOWS)
;---------------------------------------------------------------------------------------------
"%SystemRoot%",2,"D:P(A;CIOI;GRGX;;;BU)(A;CIOI;GRGWGXSD;;;PU)(A;CIOI;GA;;;BA)(A;CIOI;GA;;;SY)(A;CIOI;GA;;;CO)"

and this from setup security.inf

Code:

b8="c:\windows", 2, "D:P(A;CIOI;GRGX;;;BU)(A;CIOI;GRGWGXSD;;;PU)(A;CIOI;GA;;;BA)(A;CIOI;GA;;;SY)(A;CIOI;GA;;;CO)"

In earlier tests, I chose also to include eula.txt, located in the sysdir, as shown below.
from defltwk.inf

Code:

"%Systemdirectory%\eula.txt",2,"D:P(A;;GRGX;;;BU)(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"

and from setup security.inf

Code:

7f5="c:\windows\system32\eula.txt", 2, "D:P(A;;GRGX;;;BU)(A;;GRGX;;;PU)(A;;GA;;;BA)(A;;GA;;;SY)"

Now, also available to view are group memberships as well as general rights assigned to groups. These rights do not just apply to objects and containers, but also to registry keys and services.

The important part to recognize is that for an object, such as eula.txt, it is specifically stated that a BU (that is, Basic User) only has GRGX (that is generic read, generic execute) and that a PU (Power User) also has these same rights, but that a BA (Basic Admin) or SY (System) has GA (Generic All), which translates to the fact eula.txt can only be modified/deleted by an admin or the system.

But look further, and note that the windows directory itself, stated by the security, allows a user to only read/execute, and admin to have full control, but the flags indicate (as we all know) that there is an inheritance and progagation also involved. It SHOULD mean that all items within the windir are inheriting the same effects as the directory itself, so a user should not have some rights by inheritance. The importance of delcaring both objects and containers arise so that while you may generically say a user has no rights generically, specific objects/containers may be available for modification if specifically state and the inheritance is set correctly.

The idea of creating a file properly with proper permissions is a fine idea, however, you will have a different owner normally, as well as the possibility of inheriting different permissions that what the default security calls for.

I choose to test with what is installed and set from the beginning. For all intents and purposes, newly created files, which are not known by the OS at install, may or may not have the rights prescribed that I wonder how stripping a token will effect.

In the case of notepad, or any program, touching a file with rights set at install time, you should be able to determine whether the rights are set correctly, and whether your mechanism works properly.

When you can create an object in a container, as a user, that should be off limits, such as program files, there is a problem. When you can open a specifically stated object, such as c:\boot.ini with notepad, as an admin, and modify it, it is expected. Try that as a user, and you get an access denied. You can create an object or container in c: because you are allowed to, even as a user. You should not be able to in a container that is set to propogate and inherit correctly.

The fact that you are using notepad has no bearing, if as you say, the flags don't interfere. The fact that a default sandbox, when using the DR feature, disallows you to access c:\boot.ini, is what I would have expected.

The fact that in a sandbox using DR option, you can create/modify in the windir or program files dir, I did not expect.

I realize you work in a pseudo-virtual environment when in SBIE. Still, why it allows you, without direct access, to modify windir or an object in windir, such as eula.txt, but disallows c:\boot.ini, is a mystery.

This concludes my rebuttal. I do hope you are quite knowledgable on this because I would like to learn more.

Cheers.

Sul.

 

To make my point absolutely clear, I was talking about this:

The above conclusion is completely wrong and fully based on the notepad "DOS bug".

Yeah, that's correct. So, it works.

 

Please examine boot.ini. It is missing the BU reference. A BU should not have rights at all to this file. If a BU was assigned GRGX or GA, then they would. My results are exactly as the OS was intended.

If you open boot.ini in SBIE, it creates a copy of it in the sandbox. Once it is in there, you no longer have any permissions that deny it, because the permissions are for c:\boot.ini, not c:\sandbox\etc..\boot.ini. If you enable DR after you have opened it without DR, it can read it just fine, as no permissions prevent it. However, if you delete the contents of your sandbox, and as an admin, with DR enabled, attempt to open boot.ini, you should get "access denied", just as it should be.... unless I am so far out in left field I am hallucinating -- quite possible actually

Sul.

 

Sigh... Last time - drop boot.ini and notepad.exe from your testcase. Because it will FAIL to write anything into +RAHS boot.ini even on FAT(16/32). Case closed. Find a different tool and different object for your testing.

 

Dude, what are you talking about. Sigh... I have removed +RAHS and now it could be called -RAHS. This is not an experiment as to whether notepad has a bug at all. The fact can be proven that using notepad:

As an Admin, you CAN modify c:\boot.ini

As a User, you cannot ACCESS c:\boot.ini

I guess I don't see what you are meaning... you state it will fail to write anything to +RAHS, so what of it if those are removed, which I have stated, umm, well at least once lol.

But, for posterity sakes, and to soothe your nerves I did this.

SBIE - DR off - open cmd.exe,

Code:

echo test >> c:\boot.ini

the file now has "test" appended to end

SBIE - DR on - empty sandbox, open cmd.exe

Code:

echo test >> c:\boot.ini

the error "access denied" is thrown

There is no reason to worry about whether notepad is a useful tool, as I think it is. If this is not sufficient, please do tell, as I don't follow your reasoning.

Sul.

 

@doktornotor

I have taken what you state about notepad into account. In the interest of trying to understand what you keep stating, I fail to see how it applies here.

But, I went ahead and did some more messing around. Every program I use, whether it be command prompt, hex editors or really about anything, fails to have access to an object in c: that has been explicitly stated with permissions at install. Objects I created since install or creating new objects works just fine. But with the DR option enabled, all those items are locked from anything run in that sandbox.

This is not really important, it is just an anomoly that exists. Why would the DR option not apply WITHIN the sandbox when the token is stripped, except to those items on the root. I could ask tzuk, but I am wondering first if it is how the permissions are set within the OS that differs, causing this to be seen. The flags set in those .inf files are particuarily hidden in documentation (some of them) and I have been on the search for a few specific ones for about a year, so to me this is quite interesting.

Sul.

 

You're not able to even read boot.ini are you able to read eula.txt?
If so then the way I see it is by being able to read it sandboxie copies it over into the C:\Sandbox\etc.. if it can't be read then it can't copy it that's the only thing stopping boot.ini or any file that can't be read,
And everything else is allowed because they aren't real files they're the virtual files in C:\Sandbox\etc...

Can't say I'm too familiar with this so hopefully I'm checking the right places, Below are some things you can double check.

Here's my boot.ini line from defltwk.inf you can check it, looks the same as yours... Except for the (A;;GRGX;;;PU) which if I understand it is expected since XP Home doesn't have power users group.

Code:

"%BootDrive%\boot.ini",2,"D:P(A;;GA;;;BA)(A;;GA;;;SY)"

And here's the line from setup security.inf, again same.

Code:

2="c:\boot.ini", 2, "D:P(A;;GA;;;BA)(A;;GA;;;SY)"

And if I do a cacls in cmd for boot.ini I get BUILTIN\Users:R

 

Interesting, on xp pro, my cacls results in
Power Users : R
Administrators : F
System : F
users are not present on that file

but if I do a cacls on autoexec.bat, which is implicitly stated as well, it get
Users : R

Yes, the PU part is missing from xp home, so makes sense.

As I understand this, when you have a sandbox with nothing in it, and you enable the DR option, for some reason it treats the objects in c: with the stripped token, so that you get access denied.

If you were to not use the DR option, then when you open and modify something like boot.ini, it creates a duplicate in the virtual store, as expected, with your modifications. Whether you use cmd.exe a hex editor or the questionable notepad, it does this.

Once the file exists in the virtual store, and you then enable DR option, and open c:\boot.ini, you no longer get the access denied error. I had presumed it was because the file no longer carried the rights. But if you examine the file in the sandbox with cacls, I see that it indeed does have the same rights listed that it does on the c: drive.

In interest then, since it appears to have the same set of rights, as a user, accessing the boot.ini file within the sandbox, you can modify it, so those rights don't apply correctly, as I would imagine they do not.

If you were to copy something such as twain.dll from windir to c: drive root, it carries over the restrictions that a user may not modify it, access denied. If you are admin of course you can.

If you manually place that twain.dll file in another directory, one you have made, it is not allowed modifcation by a user.

If you place that same file, twain.dll into sandbox directory, now the user can modify it (rename etc), regardless of whether the sandbox directory in which it lives has DR enabled or not.

I don't know, it seems that when something resided in a sandbox, nothing applies as it would in the rest of the OS, which makes sense in a sense. I would have thought that placing a file there manually and then touching it with cmd.exe etc that was not sandboxed would have a different effect. I also had thought that if the DR option was enabled, it would treat things in the sandbox like the outside world.

It still does not explain why the DR option blocks access to objects default located at root, and when you transfer something there that the OS also blocks, such as twain.dll (for users) that SBIE with DR option on now ignores this. I find it a strange thing, but one worth knowing in my anal world.

Sul.

 

What is the difference between a file located at root, such as ntdetect.com and a file with basically the same rights located in windows? If you move ntdetect.com to windir, and try to modify it as a user, you get access denied. Yet in SBIE if you access it with DR enabled, you are allowed. I don't understand why it blocks it at c: but not at windir. Kinda strange.

I don't believe just opening boot.ini causes it to be placed in the virtual store, I believe you have to actually modify it before it creates it. And yes, if it can't be read it can't copy it, but I don't see it copying it anyway without modification.

This leads nowhere other than to understanding something about one of my favorite programs really. But I like learning this sort of wierd crap, as normally I walk away with a deeper understanding of things.

Sul.

 

So you should be able to open and modify autoexec.bat with DR on correct?
It looks like it needs Users:R to open it then modify to become a virtual file.
If it doesn't have Users:R then you can't even read it to be able to modify it and save it as a virtual file because it denies anyone/thing with a user group/token.

I thought the same as you that the file no longer carried the rights but after reading this I saw you were right it did have the same rights,
But after more testing I noticed somethng else.

If I check the virtual file with an unsandboxed cmd I get the same permissions.
Admin:F
System:F

And if I check c:\ntdetect.com (it's actually the virtual file) with a sandboxed cmd with DR off I get the same permissions.
Admin:F
System:F

And if I check the real ntdetect.com file with a real user account and unsandboxed I get.
Access denied

But if I check with a sandboxed cmd and DR on I get.
Authenticated Users:<OI><CI>F
(Admin account name):<OI><CI>F

Looks like It's inheriting permissions so the drop rights doesn't do anything because it's still the same user account...

Just checking but does it have the exact same rights? When you copy/paste you become owner, Now of course you probably already know that, As did I.

But I'm just checking since I still confused myself last night.
When I was messing with my boot.ini I became owner of it which added a permission if I checked the file with cacls and so changing to a user with SRP still allowed me to edit the file because I was still the same account, Took me a bit to realize why I was still able to edit the file with notepad having user permissions.

Also I forgot to mention earlier in case you're wondering about my SRP with XP Home, I'm using your PGS program, Thanks, Great program.

Yes, you're correct it has to be modified before it becomes a virtual file.
I guess I got mixed up there.

I'm the same way, The more I know the happier I am.

 

Otherwise, for the methods of checking here... Why don't you download Process Explorer, right-click on the sandboxed process there, select security tab and check the stuff there w/ DR enabled and disabled. Then you can do the same for the same process unsandboxed w/ admin and LUA.

 

Very nice. Yes, I know about ownership, which is part of why I chose to use the default files, as the account "Administrator" owns them, not my admin account. And yes, you have to be cognizant of the fact that a user and owner can be conflicting on rights.

The more I think about it, the more it leads to inheritance I believe. It is strange how it plays out, but it must be unique to how the rights on the root along with the rights of those particular files are implemented. All is well as I am keen on learning more of that .inf syntax anyway, so when I get a chance I will play with some stuff and see why. I don't think I fully appreciated the inheritance on an object. I was assuming the container did most of the propagating, but none the less it will be a good learn.

Sul.

EDIT: when I copy/pasted it, I did not check to see if I was the owner, I assume I was. But I did check it with both my admin account regular and reduced, as well as another "user" account that showed those results.

 

Oh.. good idea. I forgot about that. I was thinking of another program as well, but that would be better I think.

Please explain if possible on that notepad not being able to modify, when it does to my eyes. I am curious now beyond measure, a real itch to see what you mean, as I have never heard of this bug before.

I feel confident I can cram a few extra ounces of data into my brain

Sul.

 

Wow! I can't understand anything... but this thread is a good read

 

Well essentially what I meant is that you confused the entire thread like hell here w/ your usage of notepad and that readonly hidden boot.ini file. If you are after bypassing the sandbox, this is probably the worst tool you could get. notepad.exe is like the poor virus that cannot spread itself so asks the user for help.

 

Nope,me ether!!
But I agree,with you.

A great thread.

rat

 

lol, no, I am not trying to bypass the sandbox at all. I was just using it as a simple test to see what happens when you strip a token. Since my boot.ini file is not hidden or system or read only, notepad is capable of opening it and modifying it. The test was simple to see, if you use the DR option in SBIE, does it disallow notepad from modifying the boot.ini file, just like DMR would or SRP basic user would. The idea was not whether notepad would do anything, but whether the demoted token was passed correctly and if within the sandbox it was restricted as it would be outside the sandbox. Then it got strange because it does seem to pass the restricted token properly for things like boot.ini, but not in other areas that I would have expected it to.

I guess I don't give any thought to the attributes of such files because I know they are so and usually fix them soon after installing, at least files like boot.ini.

Glad we can provide some good reading material

Sul.

 

It is these two items, OI (object inherit) and CI (container inherit) that make up half the magic of one of those .inf files. The other mystery values are the D : P, which technically you can have more, but usually only D : PAR. There is something at work here I believe that stems from one of those values. Why SBIE seems to allow its DR option to work with objects on root differently from anywhere else is strange, but my bet is it is unintended on tzuks part. It may then be how the rights are assigned. I sure hope so, as this is one area that is super duper hard to get the real values and how to implement them.

Regardless, learning a little more about inheritance is always a good thing for serious geeks

I might post this over at SBIE forums, just to see if it is known why. Gotta love the fact that tzuk is active in doling out info...

Sul.

 

By that are you talking about being able to edit eula.txt in c:\windows\system32 but not boot.ini in c:\ ?
If so unless I'm experiencing something different than you I think that's just because of the missing Users:R

For a test if you type the following in cmd with admin permissions,

Code:

cacls c:\windows\system32\eula.txt /E /R BUILTIN\Users

That will edit (/E) the ACL and revoke (/R) the rights of Users from eula.txt, (in case you already understand that code it's for anyone else reading)
Then it should have the same permissions as your boot.ini and you should get an access denied trying to open it with DR in sandboxie turned on, But not with it off.