Adding XP in another partition users into Vi$ta

Posted October 14, 2008 · October 14, 2008

I am dual booting 32-bit XP and 64-bit Vi$ta. I wanna create a folder

that's readable by an account of the same name from both XP and Vista.

How should I do it when I boot Vi$ta?

I think I had possibly asked the same question before but I forgot....

--

@~@ Might, Courage, Vision, SINCERITY.

/ v \ Simplicity is Beauty! May the Force and Farce be with you!

/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6

^ ^ 19:54:01 up 2 days 4:37 2 users load average: 1.00 1.02 1.00

http://www.swd.gov.hk/tc/index/site_pubsvc.../sub_addressesa

Posted October 15, 2008 · October 15, 2008

You can't. You will just have to give the everyone object permission to the

folder. You cannot secure it against the security principals from the other

OS as it is not active or contactable from the one running OS.

The name of the account is irrelevant as it is actually the objects Security

ID (SID) that is placed on the Access Control Entry (ACE) on the Access

Control List (ACL) for the folder object.

(Also you appear to have a problem spelling Vista - it is an s not a $

unless you are trying to be cute like the idiots that put a $ in Microsoft.

If you have a point to make about the product do it elsewhere, if you want

to ask questions then just try referring to the product and company by their

correct names).

--

Mike Brannigan

"Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message

news:Oet8mPfLJHA.456@TK2MSFTNGP06.phx.gbl...

>

> I am dual booting 32-bit XP and 64-bit Vi$ta. I wanna create a folder

> that's readable by an account of the same name from both XP and Vista.

>

> How should I do it when I boot Vi$ta?

>

> I think I had possibly asked the same question before but I forgot....

>

> --

> @~@ Might, Courage, Vision, SINCERITY.

> / v Simplicity is Beauty! May the Force and Farce be with you!

> /( _ ) (Xubuntu 8.04.1) Linux 2.6.26.6

> ^ ^ 19:54:01 up 2 days 4:37 2 users load average: 1.00 1.02 1.00

> http://www.swd.gov.hk/tc/index/site_pubsvc.../sub_addressesa

Posted October 15, 2008 · October 15, 2008

> You can't. You will just have to give the everyone object permission to

> the folder. You cannot secure it against the security principals from

> the other OS as it is not active or contactable from the one running OS.

> The name of the account is irrelevant as it is actually the objects

> Security ID (SID) that is placed on the Access Control Entry (ACE) on

> the Access Control List (ACL) for the folder object.

Both Vi$ta and XP use the same NTFS file systems. Can't the security

wizard open the user database in another partition and extract the

relevant information?

> (Also you appear to have a problem spelling Vista - it is an s not a $

> unless you are trying to be cute like the idiots that put a $ in

> Microsoft. If you have a point to make about the product do it

> elsewhere, if you want to ask questions then just try referring to the

> product and company by their correct names).

I am not trying to be cute nor trying to promote anything. I will

continue addressing it as Vi$ta. I did spend over HK$2000 to buy my

Vi$ta Ultimate Upgrade, which would likely end up as WinMe..... style_emoticons/

--

@~@ Might, Courage, Vision, SINCERITY.

/ v \ Simplicity is Beauty! May the Force and Farce be with you!

/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6

^ ^ 22:19:01 up 3 days 7:02 2 users load average: 1.02 1.04 1.00

http://www.swd.gov.hk/tc/index/site_pubsvc.../sub_addressesa

Posted October 15, 2008 · October 15, 2008

"Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message

news:uZ7lZFtLJHA.4772@TK2MSFTNGP06.phx.gbl...

>> You can't. You will just have to give the everyone object permission to

>> the folder. You cannot secure it against the security principals from

>> the other OS as it is not active or contactable from the one running OS.

>> The name of the account is irrelevant as it is actually the objects

>> Security ID (SID) that is placed on the Access Control Entry (ACE) on the

>> Access Control List (ACL) for the folder object.

>

> Both Vi$ta and XP use the same NTFS file systems. Can't the security

> wizard open the user database in another partition and extract the

> relevant information?

>

No. The Security Account Manager (SAM) database on an instance of Windows

is more then a file to open. So one running instance on your PC cannot

access the SAM in the other operating system. If you want true cross

instance security management then you need to a move to a domain model with

Windows Servers building a shared directory service for all machines and

operating system instances, an Active Directory. (No you cannot "run" an

Active Directory in a client PC OS like XP or Vista, it is a server only

function)

Bascially within a running OS that is in a workgroup or none networked

environment the only security principals it has access to are those in its

own SAM and for other systems to access files or folder secured using NTFS

ACLs then you need to use account objects such as Guest or Everyone etc

>> (Also you appear to have a problem spelling Vista - it is an s not a $

>> unless you are trying to be cute like the idiots that put a $ in

>> Microsoft. If you have a point to make about the product do it elsewhere,

>> if you want to ask questions then just try referring to the product and

>> company by their correct names).

>

> I am not trying to be cute nor trying to promote anything. I will continue

> addressing it as Vi$ta. I did spend over HK$2000 to buy my Vi$ta Ultimate

> Upgrade, which would likely end up as WinMe..... style_emoticons/

>

Well it lacks respect.

As regards your Vista Ultimate becoming like Windows ME - there is no

possibility of that. Windows ME was a dead end product at the end of the

Win 9x product line. Windows Vista is the ongoing development of the NT

desktop operating lineage from Windows NT via Windows 2000 and Windows XP to

where we are today and onward to Windows 7 and future releases. All

effectively built on generational models of the kernel (with some backports

and cross development from the server team) and ongoing security tightening

and innovation. So Windows 7 takes all the work on Vista and continues to

move it forward, so it is worth noting that anyone thinking it will be

easier to go from XP to Windows 7 then from XP to Vista is going to be sadly

mistaken as the underlying security hardening that has caused issues with

drivers and application compatibility between XP and Vista is still there

under the cover of Windows 7, so the best and easiest migration will

actually be from Vista to Windows 7.

So no, your Windows Vista will not end up like ME.

> --

> @~@ Might, Courage, Vision, SINCERITY.

> / v Simplicity is Beauty! May the Force and Farce be with you!

> /( _ ) (Xubuntu 8.04.1) Linux 2.6.26.6

> ^ ^ 22:19:01 up 3 days 7:02 2 users load average: 1.02 1.04 1.00

> http://www.swd.gov.hk/tc/index/site_pubsvc.../sub_addressesa

--

Mike Brannigan

Posted October 15, 2008 · October 15, 2008

> So Windows 7 takes all the work on Vista and continues to move it forward,

> so it is worth noting that anyone thinking it will be easier to go from XP

> to Windows 7 then from XP to Vista is going to be sadly mistaken as the

> underlying security hardening that has caused issues with drivers and

> application compatibility between XP and Vista is still there under the

> cover of Windows 7, so the best and easiest migration will actually be

> from Vista to Windows 7.

Additionally, the virtualization features of Vista for legacy

support will not be carried forward to the new kernel.

Posted October 16, 2008 · October 16, 2008

Hello,

The common account groups are recognized between installations of Windows

(like Users and Administrators).

As long as the administrators group has full control of the file or folder,

you can add specific permissions to the object from any Windows

installation.

For example, create a folder in XP, and then in Vista add a permission to

that folder giving your Vista user account permission.

I STRONGLY CAUTION you to not change the owner of files created in another

Windows installation. This could really muck things up.

- JB

"Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message

news:Oet8mPfLJHA.456@TK2MSFTNGP06.phx.gbl...

>

> I am dual booting 32-bit XP and 64-bit Vi$ta. I wanna create a folder

> that's readable by an account of the same name from both XP and Vista.

>

> How should I do it when I boot Vi$ta?

>

> I think I had possibly asked the same question before but I forgot....

>

> --

> @~@ Might, Courage, Vision, SINCERITY.

> / v Simplicity is Beauty! May the Force and Farce be with you!

> /( _ ) (Xubuntu 8.04.1) Linux 2.6.26.6

> ^ ^ 19:54:01 up 2 days 4:37 2 users load average: 1.00 1.02 1.00

> http://www.swd.gov.hk/tc/index/site_pubsvc.../sub_addressesa

Posted October 16, 2008 · October 16, 2008

> I STRONGLY CAUTION you to not change the owner of files created in

> another Windows installation. This could really muck things up.

Too late. I did it, in that I removed the Administrator accounts from

that folder. And it seems that it's quite hard to undo the damage. ANd

that's why I asked, in that I wanna undo the damage. style_emoticons/

--

@~@ Might, Courage, Vision, SINCERITY.

/ v \ Simplicity is Beauty! May the Force and Farce be with you!

/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6

^ ^ 10:31:02 up 3 days 19:14 3 users load average: 3.02 2.82 2.51

???! ???! ???! ???! ???! ???! ????? (CSSA):

http://www.swd.gov.hk/tc/index/site_pubsvc.../sub_addressesa

Posted October 16, 2008 · October 16, 2008

> No. The Security Account Manager (SAM) database on an instance of

> Windows is more then a file to open. So one running instance on your PC

> cannot access the SAM in the other operating system. If you want true

> cross instance security management then you need to a move to a domain

> model with Windows Servers building a shared directory service for all

> machines and operating system instances, an Active Directory. (No you

> cannot "run" an Active Directory in a client PC OS like XP or Vista, it

> is a server only function)

> Bascially within a running OS that is in a workgroup or none networked

> environment the only security principals it has access to are those in

> its own SAM and for other systems to access files or folder secured

> using NTFS ACLs then you need to use account objects such as Guest or

> Everyone etc

It's just my PC, so I would not set up a domain/AD server. Besides, I am

using Linux as a home server+router.

--

@~@ Might, Courage, Vision, SINCERITY.

/ v \ Simplicity is Beauty! May the Force and Farce be with you!

/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6

^ ^ 10:32:01 up 3 days 19:15 3 users load average: 2.80 2.80 2.52

???! ???! ???! ???! ???! ???! ????? (CSSA):

http://www.swd.gov.hk/tc/index/site_pubsvc.../sub_addressesa

Posted October 16, 2008 · October 16, 2008

Re: Vi[$]ta

> Well it lacks respect.

Vi$ta is not cheap. Definitely not free as Linux. For me, it's just a

name. Did you know some people nicknamed Window$ as "WinTendo"? In fact,

at home, my 64-bit Vi$ta is more like a game console. style_emoticons/

> As regards your Vista Ultimate becoming like Windows ME - there is no

> possibility of that. Windows ME was a dead end product at the end of

> the Win 9x product line. Windows Vista is the ongoing development of

> the NT desktop operating lineage from Windows NT via Windows 2000 and

> Windows XP to where we are today and onward to Windows 7 and future

> releases. All effectively built on generational models of the kernel

> (with some backports and cross development from the server team) and

> ongoing security tightening and innovation. So Windows 7 takes all the

> work on Vista and continues to move it forward, so it is worth noting

> that anyone thinking it will be easier to go from XP to Windows 7 then

> from XP to Vista is going to be sadly mistaken as the underlying

> security hardening that has caused issues with drivers and application

> compatibility between XP and Vista is still there under the cover of

> Windows 7, so the best and easiest migration will actually be from Vista

> to Windows 7.

> So no, your Windows Vista will not end up like ME.

I skipped WinMe back then. I think others could skip Vi$ta as well.

--

@~@ Might, Courage, Vision, SINCERITY.

/ v \ Simplicity is Beauty! May the Force and Farce be with you!

/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6

^ ^ 10:34:01 up 3 days 19:17 3 users load average: 2.57 2.70 2.51

???! ???! ???! ???! ???! ???! ????? (CSSA):

http://www.swd.gov.hk/tc/index/site_pubsvc.../sub_addressesa

Posted October 16, 2008 · October 16, 2008

Can you be more specific as to what you did? You removed the administrator

account from where - permission or owner? Which folder(s), did you create

them or are they system folders?

"Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message

news:uI5UudzLJHA.4600@TK2MSFTNGP06.phx.gbl...

>> I STRONGLY CAUTION you to not change the owner of files created in

>> another Windows installation. This could really muck things up.

>

> Too late. I did it, in that I removed the Administrator accounts from that

> folder. And it seems that it's quite hard to undo the damage. ANd that's

> why I asked, in that I wanna undo the damage. style_emoticons/

>

> --

> @~@ Might, Courage, Vision, SINCERITY.

> / v Simplicity is Beauty! May the Force and Farce be with you!

> /( _ ) (Xubuntu 8.04.1) Linux 2.6.26.6

> ^ ^ 10:31:02 up 3 days 19:14 3 users load average: 3.02 2.82 2.51

> ???! ???! ???! ???! ???! ???! ????? (CSSA):

> http://www.swd.gov.hk/tc/index/site_pubsvc.../sub_addressesa

Posted October 16, 2008 · October 16, 2008

Under Vi$ta:

First, I removed all accounts that could access folder X. Then I let

user Y to take control of the folder, including subfolders. I only want

Vi$ta's user Y to access that folder.

Then I boot back into XP:

XP's Administrator as well as user could no longer access folder X,

unless I let XP's Admin to take control of folder X. But if I did that,

when I booted back into Vi$ta, Vi$ta's user Y could no longer access

folder X.

That's why I wanna add XP's Admin into access list of folder X under Vi$ta.

> Can you be more specific as to what you did? You removed the

> administrator account from where - permission or owner? Which folder(s),

> did you create them or are they system folders?

--

@~@ Might, Courage, Vision, SINCERITY.

/ v \ Simplicity is Beauty! May the Force and Farce be with you!

/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6

^ ^ 11:29:01 up 3 days 20:12 2 users load average: 10.14 9.91 9.47

http://www.swd.gov.hk/tc/index/site_pubsvc.../sub_addressesa

Posted October 16, 2008 · October 16, 2008

"Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message

news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...

> Under Vi$ta:

> First, I removed all accounts that could access folder X. Then I let user

> Y to take control of the folder, including subfolders. I only want Vi$ta's

> user Y to access that folder.

Was user Y elevated when you took ownership?

I've been wanting to ask the experts in this group about this

for awhile anyway, so here it goes.

When an SID is created by a limited user with an admin token

(elevated standard account) is the "owner" field different than

it would be without the admin token? In other words, is it only

possible to be accepted as the "owner" if you are attempting

access as that same user again also elevated?

> Then I boot back into XP:

> XP's Administrator as well as user could no longer access folder X, unless

> I let XP's Admin to take control of folder X. But if I did that, when I

> booted back into Vi$ta, Vi$ta's user Y could no longer access folder X.

Have you tried elevating Vista's Y user when attempting access of

folder X? Not because it needs elevated privileges, but because it

needs "owner" to match the SID - just in case the split token is what

is causing this confusion. Thereafter you should be able to allow any

standard user account you want to assume ownership.

Sorry if this isn't helpful, but maybe you would have better luck

in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.

Posted October 16, 2008 · October 16, 2008

If you did exactly what you said you did, you would not be able to access

the folder in Vista either, since no explicit permissions were defined.

In any case, one solution is to grant the Administrator group full control

in Vista, boot into XP and grant the XP user the desired permission, then

remove the administrator group permission if you don't want it to be there.

You should end up with at least two permissions on the file: One granting

your XP user permission, and another granting your Vista user permission.

When you look at the acl editor, you will see a username identified for one

of the permissions (the user account that exists in the running Windows

installation) and, for the other permission, an SID that represents the user

in the offline Windows installation.

- JB

"Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message

news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...

> Under Vi$ta:

> First, I removed all accounts that could access folder X. Then I let user

> Y to take control of the folder, including subfolders. I only want Vi$ta's

> user Y to access that folder.

>

> Then I boot back into XP:

> XP's Administrator as well as user could no longer access folder X, unless

> I let XP's Admin to take control of folder X. But if I did that, when I

> booted back into Vi$ta, Vi$ta's user Y could no longer access folder X.

>

> That's why I wanna add XP's Admin into access list of folder X under

> Vi$ta.

>

>> Can you be more specific as to what you did? You removed the

>> administrator account from where - permission or owner? Which folder(s),

>> did you create them or are they system folders?

>

> --

> @~@ Might, Courage, Vision, SINCERITY.

> / v Simplicity is Beauty! May the Force and Farce be with you!

> /( _ ) (Xubuntu 8.04.1) Linux 2.6.26.6

> ^ ^ 11:29:01 up 3 days 20:12 2 users load average: 10.14 9.91 9.47

> http://www.swd.gov.hk/tc/index/site_pubsvc.../sub_addressesa

Posted October 16, 2008 · October 16, 2008

Hello,

That's an excellent question.

The scenarios are different depending on whether you are logged in as a

standard user or an administrator.

When logged in as a standard user, when you elevate you are logging in with

the credentials you supply to the elevation prompt and the elevated program

is running under those credentials. So, there are actually 2 SIDs involved

and things work as you described.

Things get tricky when you are logged in as an administrator. In this case,

you only have one SID, but you get 2 tokens with different privileges when

you log in. The tricky part is that in the restricted token, your group

membership in the administrators group is set to only be considered for deny

permissions.

So, the following scenario could happen:

- You are logged in as an admin

- You are running a program that is not elevated that wants to change the

permissions on a file

- You are not granted access to the file in any permission

- The administrators group owns the file

You would not be able to use the non-elevated program to change the

permissions on the file, becase your membership in the administrators group

is being ignored when the system is deciding if you should be able to have

read/change acl access to the file by virtue of being the owner.

Of course, this scenario probably wouldn't happen in real life... the

program should know to throw a UAC prompt to get elevated.

In addition, there is also the concept of integrity levels. Most

non-elevated processes are assigned medium integrity, while an elevated

process is assigned high integrity. Every file is assigned an integrity

level.

A process can only write to a file that has an equal or lower integity level

than the process, regardless of what permissions are set or who the owner

is.

So, an un-elevated process (medium integrity) could not write to or change

the permissions on a file that has high integrity, even if your SID had full

control of the file and was the owner.

(There are no files by default that have high integrity).

- JB

"FromTheRafters" <erratic@nomail.afraid.org> wrote in message

news:u3YSsJ9LJHA.276@TK2MSFTNGP02.phx.gbl...

>

> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message

> news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...

>> Under Vi$ta:

>> First, I removed all accounts that could access folder X. Then I let user

>> Y to take control of the folder, including subfolders. I only want

>> Vi$ta's user Y to access that folder.

>

> Was user Y elevated when you took ownership?

>

> I've been wanting to ask the experts in this group about this

> for awhile anyway, so here it goes.

>

> When an SID is created by a limited user with an admin token

> (elevated standard account) is the "owner" field different than

> it would be without the admin token? In other words, is it only

> possible to be accepted as the "owner" if you are attempting

> access as that same user again also elevated?

>

>> Then I boot back into XP:

>> XP's Administrator as well as user could no longer access folder X,

>> unless I let XP's Admin to take control of folder X. But if I did that,

>> when I booted back into Vi$ta, Vi$ta's user Y could no longer access

>> folder X.

>

> Have you tried elevating Vista's Y user when attempting access of

> folder X? Not because it needs elevated privileges, but because it

> needs "owner" to match the SID - just in case the split token is what

> is causing this confusion. Thereafter you should be able to allow any

> standard user account you want to assume ownership.

>

> Sorry if this isn't helpful, but maybe you would have better luck

> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.

>

Posted October 16, 2008 · October 16, 2008

> (There are no files by default that have high integrity).

I was wrong. Any file that you create in the root of your system drive has

high integrity.

- JB

Posted October 16, 2008 · October 16, 2008

Thanks for your answer Jimmy.

Having read this:

http://www.microsoft.com/technet/prodtechn...b.mspx?mfr=true

....it had me wondering how things may have changed re Vista.

"Jimmy Brush" <jb@mvps.org> wrote in message

news:eSHYjY%23LJHA.4772@TK2MSFTNGP06.phx.gbl...

> Hello,

>

> That's an excellent question.

>

> The scenarios are different depending on whether you are logged in as a

> standard user or an administrator.

>

> When logged in as a standard user, when you elevate you are logging in

> with the credentials you supply to the elevation prompt and the elevated

> program is running under those credentials. So, there are actually 2 SIDs

> involved and things work as you described.

>

> Things get tricky when you are logged in as an administrator. In this

> case, you only have one SID, but you get 2 tokens with different

> privileges when you log in. The tricky part is that in the restricted

> token, your group membership in the administrators group is set to only be

> considered for deny permissions.

>

> So, the following scenario could happen:

>

> - You are logged in as an admin

> - You are running a program that is not elevated that wants to change the

> permissions on a file

> - You are not granted access to the file in any permission

> - The administrators group owns the file

>

> You would not be able to use the non-elevated program to change the

> permissions on the file, becase your membership in the administrators

> group is being ignored when the system is deciding if you should be able

> to have read/change acl access to the file by virtue of being the owner.

>

> Of course, this scenario probably wouldn't happen in real life... the

> program should know to throw a UAC prompt to get elevated.

>

> In addition, there is also the concept of integrity levels. Most

> non-elevated processes are assigned medium integrity, while an elevated

> process is assigned high integrity. Every file is assigned an integrity

> level.

>

> A process can only write to a file that has an equal or lower integity

> level than the process, regardless of what permissions are set or who the

> owner is.

>

> So, an un-elevated process (medium integrity) could not write to or change

> the permissions on a file that has high integrity, even if your SID had

> full control of the file and was the owner.

>

> (There are no files by default that have high integrity).

>

> - JB

>

> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

> news:u3YSsJ9LJHA.276@TK2MSFTNGP02.phx.gbl...

>>

>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message

>> news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...

>>> Under Vi$ta:

>>> First, I removed all accounts that could access folder X. Then I let

>>> user Y to take control of the folder, including subfolders. I only want

>>> Vi$ta's user Y to access that folder.

>>

>> Was user Y elevated when you took ownership?

>>

>> I've been wanting to ask the experts in this group about this

>> for awhile anyway, so here it goes.

>>

>> When an SID is created by a limited user with an admin token

>> (elevated standard account) is the "owner" field different than

>> it would be without the admin token? In other words, is it only

>> possible to be accepted as the "owner" if you are attempting

>> access as that same user again also elevated?

>>

>>> Then I boot back into XP:

>>> XP's Administrator as well as user could no longer access folder X,

>>> unless I let XP's Admin to take control of folder X. But if I did that,

>>> when I booted back into Vi$ta, Vi$ta's user Y could no longer access

>>> folder X.

>>

>> Have you tried elevating Vista's Y user when attempting access of

>> folder X? Not because it needs elevated privileges, but because it

>> needs "owner" to match the SID - just in case the split token is what

>> is causing this confusion. Thereafter you should be able to allow any

>> standard user account you want to assume ownership.

>>

>> Sorry if this isn't helpful, but maybe you would have better luck

>> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.

>>

>

Posted October 17, 2008 · October 17, 2008

If you are logged in as an administrator:

- If the program is not elevated, the owner on a new file it creates will be

the admin user SID

- If the program is elevated, the owner will be the administrators group

If you are logged in as a standard user:

- If the program is not elevated, the owner on a new file it creates will be

the standard user SID

- If the program is elevated, the owner will be the administrators group

- JB

"FromTheRafters" <erratic@nomail.afraid.org> wrote in message

news:exUKQk%23LJHA.4772@TK2MSFTNGP03.phx.gbl...

> Thanks for your answer Jimmy.

>

> Having read this:

>

> http://www.microsoft.com/technet/prodtechn...b.mspx?mfr=true

>

> ...it had me wondering how things may have changed re Vista.

>

> "Jimmy Brush" <jb@mvps.org> wrote in message

> news:eSHYjY%23LJHA.4772@TK2MSFTNGP06.phx.gbl...

>> Hello,

>>

>> That's an excellent question.

>>

>> The scenarios are different depending on whether you are logged in as a

>> standard user or an administrator.

>>

>> When logged in as a standard user, when you elevate you are logging in

>> with the credentials you supply to the elevation prompt and the elevated

>> program is running under those credentials. So, there are actually 2 SIDs

>> involved and things work as you described.

>>

>> Things get tricky when you are logged in as an administrator. In this

>> case, you only have one SID, but you get 2 tokens with different

>> privileges when you log in. The tricky part is that in the restricted

>> token, your group membership in the administrators group is set to only

>> be considered for deny permissions.

>>

>> So, the following scenario could happen:

>>

>> - You are logged in as an admin

>> - You are running a program that is not elevated that wants to change the

>> permissions on a file

>> - You are not granted access to the file in any permission

>> - The administrators group owns the file

>>

>> You would not be able to use the non-elevated program to change the

>> permissions on the file, becase your membership in the administrators

>> group is being ignored when the system is deciding if you should be able

>> to have read/change acl access to the file by virtue of being the owner.

>>

>> Of course, this scenario probably wouldn't happen in real life... the

>> program should know to throw a UAC prompt to get elevated.

>>

>> In addition, there is also the concept of integrity levels. Most

>> non-elevated processes are assigned medium integrity, while an elevated

>> process is assigned high integrity. Every file is assigned an integrity

>> level.

>>

>> A process can only write to a file that has an equal or lower integity

>> level than the process, regardless of what permissions are set or who the

>> owner is.

>>

>> So, an un-elevated process (medium integrity) could not write to or

>> change the permissions on a file that has high integrity, even if your

>> SID had full control of the file and was the owner.

>>

>> (There are no files by default that have high integrity).

>>

>> - JB

>>

>> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

>> news:u3YSsJ9LJHA.276@TK2MSFTNGP02.phx.gbl...

>>>

>>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message

>>> news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...

>>>> Under Vi$ta:

>>>> First, I removed all accounts that could access folder X. Then I let

>>>> user Y to take control of the folder, including subfolders. I only want

>>>> Vi$ta's user Y to access that folder.

>>>

>>> Was user Y elevated when you took ownership?

>>>

>>> I've been wanting to ask the experts in this group about this

>>> for awhile anyway, so here it goes.

>>>

>>> When an SID is created by a limited user with an admin token

>>> (elevated standard account) is the "owner" field different than

>>> it would be without the admin token? In other words, is it only

>>> possible to be accepted as the "owner" if you are attempting

>>> access as that same user again also elevated?

>>>

>>>> Then I boot back into XP:

>>>> XP's Administrator as well as user could no longer access folder X,

>>>> unless I let XP's Admin to take control of folder X. But if I did that,

>>>> when I booted back into Vi$ta, Vi$ta's user Y could no longer access

>>>> folder X.

>>>

>>> Have you tried elevating Vista's Y user when attempting access of

>>> folder X? Not because it needs elevated privileges, but because it

>>> needs "owner" to match the SID - just in case the split token is what

>>> is causing this confusion. Thereafter you should be able to allow any

>>> standard user account you want to assume ownership.

>>>

>>> Sorry if this isn't helpful, but maybe you would have better luck

>>> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.

>>>

>>

>

>

Posted October 17, 2008 · October 17, 2008

Also, you can assign ownership to an arbitrary user or group in Vista

through the ACL editor UI, with the appropriate rights of course.

- JB

"FromTheRafters" <erratic@nomail.afraid.org> wrote in message

news:exUKQk%23LJHA.4772@TK2MSFTNGP03.phx.gbl...

> Thanks for your answer Jimmy.

>

> Having read this:

>

> http://www.microsoft.com/technet/prodtechn...b.mspx?mfr=true

>

> ...it had me wondering how things may have changed re Vista.

>

> "Jimmy Brush" <jb@mvps.org> wrote in message

> news:eSHYjY%23LJHA.4772@TK2MSFTNGP06.phx.gbl...

>> Hello,

>>

>> That's an excellent question.

>>

>> The scenarios are different depending on whether you are logged in as a

>> standard user or an administrator.

>>

>> When logged in as a standard user, when you elevate you are logging in

>> with the credentials you supply to the elevation prompt and the elevated

>> program is running under those credentials. So, there are actually 2 SIDs

>> involved and things work as you described.

>>

>> Things get tricky when you are logged in as an administrator. In this

>> case, you only have one SID, but you get 2 tokens with different

>> privileges when you log in. The tricky part is that in the restricted

>> token, your group membership in the administrators group is set to only

>> be considered for deny permissions.

>>

>> So, the following scenario could happen:

>>

>> - You are logged in as an admin

>> - You are running a program that is not elevated that wants to change the

>> permissions on a file

>> - You are not granted access to the file in any permission

>> - The administrators group owns the file

>>

>> You would not be able to use the non-elevated program to change the

>> permissions on the file, becase your membership in the administrators

>> group is being ignored when the system is deciding if you should be able

>> to have read/change acl access to the file by virtue of being the owner.

>>

>> Of course, this scenario probably wouldn't happen in real life... the

>> program should know to throw a UAC prompt to get elevated.

>>

>> In addition, there is also the concept of integrity levels. Most

>> non-elevated processes are assigned medium integrity, while an elevated

>> process is assigned high integrity. Every file is assigned an integrity

>> level.

>>

>> A process can only write to a file that has an equal or lower integity

>> level than the process, regardless of what permissions are set or who the

>> owner is.

>>

>> So, an un-elevated process (medium integrity) could not write to or

>> change the permissions on a file that has high integrity, even if your

>> SID had full control of the file and was the owner.

>>

>> (There are no files by default that have high integrity).

>>

>> - JB

>>

>> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

>> news:u3YSsJ9LJHA.276@TK2MSFTNGP02.phx.gbl...

>>>

>>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message

>>> news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...

>>>> Under Vi$ta:

>>>> First, I removed all accounts that could access folder X. Then I let

>>>> user Y to take control of the folder, including subfolders. I only want

>>>> Vi$ta's user Y to access that folder.

>>>

>>> Was user Y elevated when you took ownership?

>>>

>>> I've been wanting to ask the experts in this group about this

>>> for awhile anyway, so here it goes.

>>>

>>> When an SID is created by a limited user with an admin token

>>> (elevated standard account) is the "owner" field different than

>>> it would be without the admin token? In other words, is it only

>>> possible to be accepted as the "owner" if you are attempting

>>> access as that same user again also elevated?

>>>

>>>> Then I boot back into XP:

>>>> XP's Administrator as well as user could no longer access folder X,

>>>> unless I let XP's Admin to take control of folder X. But if I did that,

>>>> when I booted back into Vi$ta, Vi$ta's user Y could no longer access

>>>> folder X.

>>>

>>> Have you tried elevating Vista's Y user when attempting access of

>>> folder X? Not because it needs elevated privileges, but because it

>>> needs "owner" to match the SID - just in case the split token is what

>>> is causing this confusion. Thereafter you should be able to allow any

>>> standard user account you want to assume ownership.

>>>

>>> Sorry if this isn't helpful, but maybe you would have better luck

>>> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.

>>>

>>

>

>

Posted October 17, 2008 · October 17, 2008

Man-wai Chang ToDie (33.6k) wrote:

>> I STRONGLY CAUTION you to not change the owner of files created in

>> another Windows installation. This could really muck things up.

>

> Too late. I did it, in that I removed the Administrator accounts from

> that folder. And it seems that it's quite hard to undo the damage. ANd

> that's why I asked, in that I wanna undo the damage. style_emoticons/

>

I thought of a simpler solution: copy the folder into a new folder name

as administrator. That new folder should have the default ownership and

permission while in XP. Then I boot back into Vi$ta and add Vi$ta's

corresponding accounts into the security list.

--

@~@ Might, Courage, Vision, SINCERITY.

/ v \ Simplicity is Beauty! May the Force and Farce be with you!

/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6

^ ^ 15:17:01 up 2:23 3 users load average: 1.00 1.38 1.44

???! ???! ???! ???! ???! ???! ????? (CSSA):

http://www.swd.gov.hk/tc/index/site_pubsvc.../sub_addressesa

Posted October 17, 2008 · October 17, 2008

So, this is the reason a user cannot use IE to download

a program file and save it to the C:\ directory? It is not

UAC/permissions/ownership but rather integrity level

with NO_WRITE_UP (from IE to C:\ )?

But UAC gets blamed for everything. style_emoticons/)

"Jimmy Brush" <jb@mvps.org> wrote in message

news:ee%230Pi%23LJHA.4772@TK2MSFTNGP03.phx.gbl...

>> (There are no files by default that have high integrity).

>

> I was wrong. Any file that you create in the root of your system drive has

> high integrity.

>

> - JB

Posted October 17, 2008 · October 17, 2008

Can you confirm this? It was my understanding that you can

only grant the permission for another to take ownership and

not simply assign ownership to another (for auditing purposes

to avoid someone taking ownership, making nefarious changes

and then assigning ownership to a scapegoat).

....again, this was from the W2K link - but I don't see why

that would change in Vista (unless they've improved on the

audit trail).

"Jimmy Brush" <jb@mvps.org> wrote in message

news:Os9bZ1%23LJHA.3080@TK2MSFTNGP06.phx.gbl...

> Also, you can assign ownership to an arbitrary user or group in Vista

> through the ACL editor UI, with the appropriate rights of course.

>

> - JB

>

> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

> news:exUKQk%23LJHA.4772@TK2MSFTNGP03.phx.gbl...

>> Thanks for your answer Jimmy.

>>

>> Having read this:

>>

>> http://www.microsoft.com/technet/prodtechn...b.mspx?mfr=true

>>

>> ...it had me wondering how things may have changed re Vista.

>>

>> "Jimmy Brush" <jb@mvps.org> wrote in message

>> news:eSHYjY%23LJHA.4772@TK2MSFTNGP06.phx.gbl...

>>> Hello,

>>>

>>> That's an excellent question.

>>>

>>> The scenarios are different depending on whether you are logged in as a

>>> standard user or an administrator.

>>>

>>> When logged in as a standard user, when you elevate you are logging in

>>> with the credentials you supply to the elevation prompt and the elevated

>>> program is running under those credentials. So, there are actually 2

>>> SIDs involved and things work as you described.

>>>

>>> Things get tricky when you are logged in as an administrator. In this

>>> case, you only have one SID, but you get 2 tokens with different

>>> privileges when you log in. The tricky part is that in the restricted

>>> token, your group membership in the administrators group is set to only

>>> be considered for deny permissions.

>>>

>>> So, the following scenario could happen:

>>>

>>> - You are logged in as an admin

>>> - You are running a program that is not elevated that wants to change

>>> the permissions on a file

>>> - You are not granted access to the file in any permission

>>> - The administrators group owns the file

>>>

>>> You would not be able to use the non-elevated program to change the

>>> permissions on the file, becase your membership in the administrators

>>> group is being ignored when the system is deciding if you should be able

>>> to have read/change acl access to the file by virtue of being the owner.

>>>

>>> Of course, this scenario probably wouldn't happen in real life... the

>>> program should know to throw a UAC prompt to get elevated.

>>>

>>> In addition, there is also the concept of integrity levels. Most

>>> non-elevated processes are assigned medium integrity, while an elevated

>>> process is assigned high integrity. Every file is assigned an integrity

>>> level.

>>>

>>> A process can only write to a file that has an equal or lower integity

>>> level than the process, regardless of what permissions are set or who

>>> the owner is.

>>>

>>> So, an un-elevated process (medium integrity) could not write to or

>>> change the permissions on a file that has high integrity, even if your

>>> SID had full control of the file and was the owner.

>>>

>>> (There are no files by default that have high integrity).

>>>

>>> - JB

>>>

>>> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

>>> news:u3YSsJ9LJHA.276@TK2MSFTNGP02.phx.gbl...

>>>>

>>>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in

>>>> message news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...

>>>>> Under Vi$ta:

>>>>> First, I removed all accounts that could access folder X. Then I let

>>>>> user Y to take control of the folder, including subfolders. I only

>>>>> want Vi$ta's user Y to access that folder.

>>>>

>>>> Was user Y elevated when you took ownership?

>>>>

>>>> I've been wanting to ask the experts in this group about this

>>>> for awhile anyway, so here it goes.

>>>>

>>>> When an SID is created by a limited user with an admin token

>>>> (elevated standard account) is the "owner" field different than

>>>> it would be without the admin token? In other words, is it only

>>>> possible to be accepted as the "owner" if you are attempting

>>>> access as that same user again also elevated?

>>>>

>>>>> Then I boot back into XP:

>>>>> XP's Administrator as well as user could no longer access folder X,

>>>>> unless I let XP's Admin to take control of folder X. But if I did

>>>>> that, when I booted back into Vi$ta, Vi$ta's user Y could no longer

>>>>> access folder X.

>>>>

>>>> Have you tried elevating Vista's Y user when attempting access of

>>>> folder X? Not because it needs elevated privileges, but because it

>>>> needs "owner" to match the SID - just in case the split token is what

>>>> is causing this confusion. Thereafter you should be able to allow any

>>>> standard user account you want to assume ownership.

>>>>

>>>> Sorry if this isn't helpful, but maybe you would have better luck

>>>> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.

>>>>

>>>

>>

>>

>

Posted October 17, 2008 · October 17, 2008

Yup style_emoticons/. You have to hold the restore privilege (admins have it by default).

This isn't new functionality to Vista, it was just never exposed in the UI

before.

http://support.microsoft.com/kb/245153/EN-US/

I am not aware of any auditing enhancements.

- JB

"FromTheRafters" <erratic@nomail.afraid.org> wrote in message

news:%23RqSSMJMJHA.3744@TK2MSFTNGP06.phx.gbl...

> Can you confirm this? It was my understanding that you can

> only grant the permission for another to take ownership and

> not simply assign ownership to another (for auditing purposes

> to avoid someone taking ownership, making nefarious changes

> and then assigning ownership to a scapegoat).

>

> ...again, this was from the W2K link - but I don't see why

> that would change in Vista (unless they've improved on the

> audit trail).

>

> "Jimmy Brush" <jb@mvps.org> wrote in message

> news:Os9bZ1%23LJHA.3080@TK2MSFTNGP06.phx.gbl...

>> Also, you can assign ownership to an arbitrary user or group in Vista

>> through the ACL editor UI, with the appropriate rights of course.

>>

>> - JB

>>

>> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

>> news:exUKQk%23LJHA.4772@TK2MSFTNGP03.phx.gbl...

>>> Thanks for your answer Jimmy.

>>>

>>> Having read this:

>>>

>>> http://www.microsoft.com/technet/prodtechn...b.mspx?mfr=true

>>>

>>> ...it had me wondering how things may have changed re Vista.

>>>

>>> "Jimmy Brush" <jb@mvps.org> wrote in message

>>> news:eSHYjY%23LJHA.4772@TK2MSFTNGP06.phx.gbl...

>>>> Hello,

>>>>

>>>> That's an excellent question.

>>>>

>>>> The scenarios are different depending on whether you are logged in as a

>>>> standard user or an administrator.

>>>>

>>>> When logged in as a standard user, when you elevate you are logging in

>>>> with the credentials you supply to the elevation prompt and the

>>>> elevated program is running under those credentials. So, there are

>>>> actually 2 SIDs involved and things work as you described.

>>>>

>>>> Things get tricky when you are logged in as an administrator. In this

>>>> case, you only have one SID, but you get 2 tokens with different

>>>> privileges when you log in. The tricky part is that in the restricted

>>>> token, your group membership in the administrators group is set to only

>>>> be considered for deny permissions.

>>>>

>>>> So, the following scenario could happen:

>>>>

>>>> - You are logged in as an admin

>>>> - You are running a program that is not elevated that wants to change

>>>> the permissions on a file

>>>> - You are not granted access to the file in any permission

>>>> - The administrators group owns the file

>>>>

>>>> You would not be able to use the non-elevated program to change the

>>>> permissions on the file, becase your membership in the administrators

>>>> group is being ignored when the system is deciding if you should be

>>>> able to have read/change acl access to the file by virtue of being the

>>>> owner.

>>>>

>>>> Of course, this scenario probably wouldn't happen in real life... the

>>>> program should know to throw a UAC prompt to get elevated.

>>>>

>>>> In addition, there is also the concept of integrity levels. Most

>>>> non-elevated processes are assigned medium integrity, while an elevated

>>>> process is assigned high integrity. Every file is assigned an integrity

>>>> level.

>>>>

>>>> A process can only write to a file that has an equal or lower integity

>>>> level than the process, regardless of what permissions are set or who

>>>> the owner is.

>>>>

>>>> So, an un-elevated process (medium integrity) could not write to or

>>>> change the permissions on a file that has high integrity, even if your

>>>> SID had full control of the file and was the owner.

>>>>

>>>> (There are no files by default that have high integrity).

>>>>

>>>> - JB

>>>>

>>>> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

>>>> news:u3YSsJ9LJHA.276@TK2MSFTNGP02.phx.gbl...

>>>>>

>>>>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in

>>>>> message news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...

>>>>>> Under Vi$ta:

>>>>>> First, I removed all accounts that could access folder X. Then I let

>>>>>> user Y to take control of the folder, including subfolders. I only

>>>>>> want Vi$ta's user Y to access that folder.

>>>>>

>>>>> Was user Y elevated when you took ownership?

>>>>>

>>>>> I've been wanting to ask the experts in this group about this

>>>>> for awhile anyway, so here it goes.

>>>>>

>>>>> When an SID is created by a limited user with an admin token

>>>>> (elevated standard account) is the "owner" field different than

>>>>> it would be without the admin token? In other words, is it only

>>>>> possible to be accepted as the "owner" if you are attempting

>>>>> access as that same user again also elevated?

>>>>>

>>>>>> Then I boot back into XP:

>>>>>> XP's Administrator as well as user could no longer access folder X,

>>>>>> unless I let XP's Admin to take control of folder X. But if I did

>>>>>> that, when I booted back into Vi$ta, Vi$ta's user Y could no longer

>>>>>> access folder X.

>>>>>

>>>>> Have you tried elevating Vista's Y user when attempting access of

>>>>> folder X? Not because it needs elevated privileges, but because it

>>>>> needs "owner" to match the SID - just in case the split token is what

>>>>> is causing this confusion. Thereafter you should be able to allow any

>>>>> standard user account you want to assume ownership.

>>>>>

>>>>> Sorry if this isn't helpful, but maybe you would have better luck

>>>>> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.

>>>>>

>>>>

>>>

>>>

>>

>

>

Posted October 17, 2008 · October 17, 2008

It's not just from IE ... it is any non-elevated program. The problem is

kind of interesting.

The actual ACL entry on the root drive is:

Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW)

Which means the label should only be applied to files that are created

beneath the root drive one level deep, with a no-write-up policy.

So the root drive itself has no label... theoretically, you should be able

to give yourself permission and create files.

But if you do that and try to create a file, you will get the error "A

required privilege is not held by the client."

Hmm... interesting. Ah... there is a security policy that says a process

cannot create a securable object that has a higher integrity than the

process, unless it has the SE_RELABEL_NAME privilege.

So it looks like it's failing because of that.

- JB

"FromTheRafters" <erratic@nomail.afraid.org> wrote in message

news:%23Se16EJMJHA.4536@TK2MSFTNGP03.phx.gbl...

> So, this is the reason a user cannot use IE to download

> a program file and save it to the C: directory? It is not

> UAC/permissions/ownership but rather integrity level

> with NO_WRITE_UP (from IE to C: )?

>

> But UAC gets blamed for everything. style_emoticons/)

>

> "Jimmy Brush" <jb@mvps.org> wrote in message

> news:ee%230Pi%23LJHA.4772@TK2MSFTNGP03.phx.gbl...

>>> (There are no files by default that have high integrity).

>>

>> I was wrong. Any file that you create in the root of your system drive

>> has high integrity.

>>

>> - JB

>

>

Posted October 18, 2008 · October 18, 2008

It was this bit that got me thinking that...

"The Owner tab shown in Figure 12.19 has no option for giving ownership to

another individual. If that were possible, an unscrupulous user could take

ownership, do something wrong, and then cover his tracks by giving ownership

to someone else. To prevent that from happening, the operating system does

not support a give ownership operation at any levelnot in the user

interface, not in application programming interfaces. It is true that a

program can write new information in the Owner field of an objects security

descriptor if the process has WRITE_OWNER access to the object, but

WRITE_OWNER access permits the caller to change ownership only to the user

SID in the callers access token or, if the user is a member of the

Administrators group, to the Administrators SID. Thus it is never possible

to give ownership of an object to another user. If you want to transfer

ownership of an object, you must give another user permission to take

ownership and then wait until the other user takes it."

"Jimmy Brush" <jb@mvps.org> wrote in message

news:%237ugJRKMJHA.4772@TK2MSFTNGP03.phx.gbl...

> Yup style_emoticons/. You have to hold the restore privilege (admins have it by

> default).

>

> This isn't new functionality to Vista, it was just never exposed in the UI

> before.

>

> http://support.microsoft.com/kb/245153/EN-US/

>

> I am not aware of any auditing enhancements.

>

> - JB

>

> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

> news:%23RqSSMJMJHA.3744@TK2MSFTNGP06.phx.gbl...

>> Can you confirm this? It was my understanding that you can

>> only grant the permission for another to take ownership and

>> not simply assign ownership to another (for auditing purposes

>> to avoid someone taking ownership, making nefarious changes

>> and then assigning ownership to a scapegoat).

>>

>> ...again, this was from the W2K link - but I don't see why

>> that would change in Vista (unless they've improved on the

>> audit trail).

>>

>> "Jimmy Brush" <jb@mvps.org> wrote in message

>> news:Os9bZ1%23LJHA.3080@TK2MSFTNGP06.phx.gbl...

>>> Also, you can assign ownership to an arbitrary user or group in Vista

>>> through the ACL editor UI, with the appropriate rights of course.

>>>

>>> - JB

>>>

>>> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

>>> news:exUKQk%23LJHA.4772@TK2MSFTNGP03.phx.gbl...

>>>> Thanks for your answer Jimmy.

>>>>

>>>> Having read this:

>>>>

>>>> http://www.microsoft.com/technet/prodtechn...b.mspx?mfr=true

>>>>

>>>> ...it had me wondering how things may have changed re Vista.

>>>>

>>>> "Jimmy Brush" <jb@mvps.org> wrote in message

>>>> news:eSHYjY%23LJHA.4772@TK2MSFTNGP06.phx.gbl...

>>>>> Hello,

>>>>>

>>>>> That's an excellent question.

>>>>>

>>>>> The scenarios are different depending on whether you are logged in as

>>>>> a standard user or an administrator.

>>>>>

>>>>> When logged in as a standard user, when you elevate you are logging in

>>>>> with the credentials you supply to the elevation prompt and the

>>>>> elevated program is running under those credentials. So, there are

>>>>> actually 2 SIDs involved and things work as you described.

>>>>>

>>>>> Things get tricky when you are logged in as an administrator. In this

>>>>> case, you only have one SID, but you get 2 tokens with different

>>>>> privileges when you log in. The tricky part is that in the restricted

>>>>> token, your group membership in the administrators group is set to

>>>>> only be considered for deny permissions.

>>>>>

>>>>> So, the following scenario could happen:

>>>>>

>>>>> - You are logged in as an admin

>>>>> - You are running a program that is not elevated that wants to change

>>>>> the permissions on a file

>>>>> - You are not granted access to the file in any permission

>>>>> - The administrators group owns the file

>>>>>

>>>>> You would not be able to use the non-elevated program to change the

>>>>> permissions on the file, becase your membership in the administrators

>>>>> group is being ignored when the system is deciding if you should be

>>>>> able to have read/change acl access to the file by virtue of being the

>>>>> owner.

>>>>>

>>>>> Of course, this scenario probably wouldn't happen in real life... the

>>>>> program should know to throw a UAC prompt to get elevated.

>>>>>

>>>>> In addition, there is also the concept of integrity levels. Most

>>>>> non-elevated processes are assigned medium integrity, while an

>>>>> elevated process is assigned high integrity. Every file is assigned an

>>>>> integrity level.

>>>>>

>>>>> A process can only write to a file that has an equal or lower integity

>>>>> level than the process, regardless of what permissions are set or who

>>>>> the owner is.

>>>>>

>>>>> So, an un-elevated process (medium integrity) could not write to or

>>>>> change the permissions on a file that has high integrity, even if your

>>>>> SID had full control of the file and was the owner.

>>>>>

>>>>> (There are no files by default that have high integrity).

>>>>>

>>>>> - JB

>>>>>

>>>>> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

>>>>> news:u3YSsJ9LJHA.276@TK2MSFTNGP02.phx.gbl...

>>>>>>

>>>>>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in

>>>>>> message news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...

>>>>>>> Under Vi$ta:

>>>>>>> First, I removed all accounts that could access folder X. Then I let

>>>>>>> user Y to take control of the folder, including subfolders. I only

>>>>>>> want Vi$ta's user Y to access that folder.

>>>>>>

>>>>>> Was user Y elevated when you took ownership?

>>>>>>

>>>>>> I've been wanting to ask the experts in this group about this

>>>>>> for awhile anyway, so here it goes.

>>>>>>

>>>>>> When an SID is created by a limited user with an admin token

>>>>>> (elevated standard account) is the "owner" field different than

>>>>>> it would be without the admin token? In other words, is it only

>>>>>> possible to be accepted as the "owner" if you are attempting

>>>>>> access as that same user again also elevated?

>>>>>>

>>>>>>> Then I boot back into XP:

>>>>>>> XP's Administrator as well as user could no longer access folder X,

>>>>>>> unless I let XP's Admin to take control of folder X. But if I did

>>>>>>> that, when I booted back into Vi$ta, Vi$ta's user Y could no longer

>>>>>>> access folder X.

>>>>>>

>>>>>> Have you tried elevating Vista's Y user when attempting access of

>>>>>> folder X? Not because it needs elevated privileges, but because it

>>>>>> needs "owner" to match the SID - just in case the split token is what

>>>>>> is causing this confusion. Thereafter you should be able to allow any

>>>>>> standard user account you want to assume ownership.

>>>>>>

>>>>>> Sorry if this isn't helpful, but maybe you would have better luck

>>>>>> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.

>>>>>>

>>>>>

>>>>

>>>

>>

>>

>

Posted October 19, 2008 · October 19, 2008

The statement about there being no API to do it is just plain wrong. I guess

sometimes the left hand doesn't know what the right hand is doing style_emoticons/.

If Windows didn't support some mechanism for allowing a group of users to

set the owner on a file, the Windows backup program could not correctly

restore backups.

One can always remove this capability by not granting Administrators the

restore privilege.

- JB

"FromTheRafters" <erratic@nomail.afraid.org> wrote in message

news:e2cOBjXMJHA.3744@TK2MSFTNGP05.phx.gbl...

> It was this bit that got me thinking that...

>

> "The Owner tab shown in Figure 12.19 has no option for giving ownership to

> another individual. If that were possible, an unscrupulous user could take

> ownership, do something wrong, and then cover his tracks by giving

> ownership to someone else. To prevent that from happening, the operating

> system does not support a give ownership operation at any levelnot in the

> user interface, not in application programming interfaces. It is true that

> a program can write new information in the Owner field of an objects

> security descriptor if the process has WRITE_OWNER access to the object,

> but WRITE_OWNER access permits the caller to change ownership only to the

> user SID in the callers access token or, if the user is a member of the

> Administrators group, to the Administrators SID. Thus it is never possible

> to give ownership of an object to another user. If you want to transfer

> ownership of an object, you must give another user permission to take

> ownership and then wait until the other user takes it."

>

> "Jimmy Brush" <jb@mvps.org> wrote in message

> news:%237ugJRKMJHA.4772@TK2MSFTNGP03.phx.gbl...

>> Yup style_emoticons/. You have to hold the restore privilege (admins have it by

>> default).

>>

>> This isn't new functionality to Vista, it was just never exposed in the

>> UI before.

>>

>> http://support.microsoft.com/kb/245153/EN-US/

>>

>> I am not aware of any auditing enhancements.

>>

>> - JB

>>

>> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

>> news:%23RqSSMJMJHA.3744@TK2MSFTNGP06.phx.gbl...

>>> Can you confirm this? It was my understanding that you can

>>> only grant the permission for another to take ownership and

>>> not simply assign ownership to another (for auditing purposes

>>> to avoid someone taking ownership, making nefarious changes

>>> and then assigning ownership to a scapegoat).

>>>

>>> ...again, this was from the W2K link - but I don't see why

>>> that would change in Vista (unless they've improved on the

>>> audit trail).

>>>

>>> "Jimmy Brush" <jb@mvps.org> wrote in message

>>> news:Os9bZ1%23LJHA.3080@TK2MSFTNGP06.phx.gbl...

>>>> Also, you can assign ownership to an arbitrary user or group in Vista

>>>> through the ACL editor UI, with the appropriate rights of course.

>>>>

>>>> - JB

>>>>

>>>> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

>>>> news:exUKQk%23LJHA.4772@TK2MSFTNGP03.phx.gbl...

>>>>> Thanks for your answer Jimmy.

>>>>>

>>>>> Having read this:

>>>>>

>>>>> http://www.microsoft.com/technet/prodtechn...b.mspx?mfr=true

>>>>>

>>>>> ...it had me wondering how things may have changed re Vista.

>>>>>

>>>>> "Jimmy Brush" <jb@mvps.org> wrote in message

>>>>> news:eSHYjY%23LJHA.4772@TK2MSFTNGP06.phx.gbl...

>>>>>> Hello,

>>>>>>

>>>>>> That's an excellent question.

>>>>>>

>>>>>> The scenarios are different depending on whether you are logged in as

>>>>>> a standard user or an administrator.

>>>>>>

>>>>>> When logged in as a standard user, when you elevate you are logging

>>>>>> in with the credentials you supply to the elevation prompt and the

>>>>>> elevated program is running under those credentials. So, there are

>>>>>> actually 2 SIDs involved and things work as you described.

>>>>>>

>>>>>> Things get tricky when you are logged in as an administrator. In this

>>>>>> case, you only have one SID, but you get 2 tokens with different

>>>>>> privileges when you log in. The tricky part is that in the restricted

>>>>>> token, your group membership in the administrators group is set to

>>>>>> only be considered for deny permissions.

>>>>>>

>>>>>> So, the following scenario could happen:

>>>>>>

>>>>>> - You are logged in as an admin

>>>>>> - You are running a program that is not elevated that wants to change

>>>>>> the permissions on a file

>>>>>> - You are not granted access to the file in any permission

>>>>>> - The administrators group owns the file

>>>>>>

>>>>>> You would not be able to use the non-elevated program to change the

>>>>>> permissions on the file, becase your membership in the administrators

>>>>>> group is being ignored when the system is deciding if you should be

>>>>>> able to have read/change acl access to the file by virtue of being

>>>>>> the owner.

>>>>>>

>>>>>> Of course, this scenario probably wouldn't happen in real life... the

>>>>>> program should know to throw a UAC prompt to get elevated.

>>>>>>

>>>>>> In addition, there is also the concept of integrity levels. Most

>>>>>> non-elevated processes are assigned medium integrity, while an

>>>>>> elevated process is assigned high integrity. Every file is assigned

>>>>>> an integrity level.

>>>>>>

>>>>>> A process can only write to a file that has an equal or lower

>>>>>> integity level than the process, regardless of what permissions are

>>>>>> set or who the owner is.

>>>>>>

>>>>>> So, an un-elevated process (medium integrity) could not write to or

>>>>>> change the permissions on a file that has high integrity, even if

>>>>>> your SID had full control of the file and was the owner.

>>>>>>

>>>>>> (There are no files by default that have high integrity).

>>>>>>

>>>>>> - JB

>>>>>>

>>>>>> "FromTheRafters" <erratic@nomail.afraid.org> wrote in message

>>>>>> news:u3YSsJ9LJHA.276@TK2MSFTNGP02.phx.gbl...

>>>>>>>

>>>>>>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in

>>>>>>> message news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...

>>>>>>>> Under Vi$ta:

>>>>>>>> First, I removed all accounts that could access folder X. Then I

>>>>>>>> let user Y to take control of the folder, including subfolders. I

>>>>>>>> only want Vi$ta's user Y to access that folder.

>>>>>>>

>>>>>>> Was user Y elevated when you took ownership?

>>>>>>>

>>>>>>> I've been wanting to ask the experts in this group about this

>>>>>>> for awhile anyway, so here it goes.

>>>>>>>

>>>>>>> When an SID is created by a limited user with an admin token

>>>>>>> (elevated standard account) is the "owner" field different than

>>>>>>> it would be without the admin token? In other words, is it only

>>>>>>> possible to be accepted as the "owner" if you are attempting

>>>>>>> access as that same user again also elevated?

>>>>>>>

>>>>>>>> Then I boot back into XP:

>>>>>>>> XP's Administrator as well as user could no longer access folder X,

>>>>>>>> unless I let XP's Admin to take control of folder X. But if I did

>>>>>>>> that, when I booted back into Vi$ta, Vi$ta's user Y could no longer

>>>>>>>> access folder X.

>>>>>>>

>>>>>>> Have you tried elevating Vista's Y user when attempting access of

>>>>>>> folder X? Not because it needs elevated privileges, but because it

>>>>>>> needs "owner" to match the SID - just in case the split token is

>>>>>>> what

>>>>>>> is causing this confusion. Thereafter you should be able to allow

>>>>>>> any

>>>>>>> standard user account you want to assume ownership.

>>>>>>>

>>>>>>> Sorry if this isn't helpful, but maybe you would have better luck

>>>>>>> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.

>>>>>>>

>>>>>>

>>>>>

>>>>

>>>

>>>

>>

>

>

Sign In

Adding XP in another partition users into Vi$ta

Recommended Posts

Guest Man-wai Chang ToDie (33.6k)

Popular Days

Popular Days

Guest Mike Brannigan

Guest Man-wai Chang ToDie (33.6k)

Guest Mike Brannigan

Guest FromTheRafters

Guest Jimmy Brush

Guest Man-wai Chang ToDie (33.6k)

Guest Man-wai Chang ToDie (33.6k)

Guest Man-wai Chang ToDie (33.6k)

Guest Jimmy Brush

Guest Man-wai Chang ToDie (33.6k)

Guest FromTheRafters

Guest Jimmy Brush

Guest Jimmy Brush

Guest Jimmy Brush

Guest FromTheRafters

Guest Jimmy Brush

Guest Jimmy Brush

Guest Man-wai Chang ToDie (33.6k)

Guest FromTheRafters

Guest FromTheRafters

Guest Jimmy Brush

Guest Jimmy Brush

Guest FromTheRafters

Guest Jimmy Brush

Join the conversation

Browse

Activity

Support