Default c:\ Perms allows auth users to make folders.

[DrCheese]

Hi,

Anyone else find it strange how Windows 7 by default allows all authenticated users to create folders on the c:\ drive?

There is an ACL for authenticated users to create folders, once they've made that folder they can dump whatever they want in there.

 

According to the technet forums, it's safe to remove this ACL

Should Authenticated Users group have Modify privileges in C:\ root directory? How do I harden it?

 

I'm just a little paranoid about removing it myself although I can't see why on earth it would be required and as such I'd rather just get rid of it. If I remove it users get a UAC prompt if they try to do it in future.

 

Has anyone else done this? Or am I being over cautious? Granted I have c:\ access locked down on the students but still.

[chrisbrown]

Go for it. I reckon as long as your users still have full control over %userprofile% then they should be right...someone correct me if I'm wrong.

[sukh]

Hi

 

@Chrisbrown, you are correct. We have set this up on many deployments.

 

Regards

Sukh

[Arthur]

I can't see why on earth it would be required and as such I'd rather just get rid of it. If I remove it users get a UAC prompt if they try to do it in future.

Are they set this way for compatibility reasons (legacy apps which attempt to write to the root of the C: drive)? When you browse to C:\ in Windows Explorer, there's a "Compatibility Files" button on the toolbar, which when clicked shows files stored in the user's VirtualStore folder. Although the UAC file virtualization driver (luafv.sys) doesn't deal with C:\, I still find files which should have been written to the root of C: in my VirtualStore folder.

 

The file system locations that are virtualised for legacy processes are %ProgramFiles%, %ProgramData% and %SystemRoot%, excluding some specific subdirectories. However, any file with an executable extension, including .exe, .bat, .scr, .vbs, and others, is excluded from virtualisation. This means that programs that update themselves from a standard user account fail instead of creating private versions of their executables that aren’t visible to an administrator running a global updater. (Source)

[flyinghaggis]

Hi,

Anyone else find it strange how Windows 7 by default allows all authenticated users to create folders on the c:\ drive?

There is an ACL for authenticated users to create folders, once they've made that folder they can dump whatever they want in there.

 

According to the technet forums, it's safe to remove this ACL

Should Authenticated Users group have Modify privileges in C:\ root directory? How do I harden it?

 

I'm just a little paranoid about removing it myself although I can't see why on earth it would be required and as such I'd rather just get rid of it. If I remove it users get a UAC prompt if they try to do it in future.

 

Has anyone else done this? Or am I being over cautious? Granted I have c:\ access locked down on the students but still.

 

We've noticed this still seems to be the default setting even on our newly installed Windows 10 computers. I presume it's like this for legacy support reasons but it seems hugely insecure and outright dangerous that *any* authenticated user on a computer can create files/folders on the root of a system drive which everyone else can access?

 

Has anyone changed this setting and if so did it have any negative impact? I feel like it's something that really should be restricted but I'm apprehensive about making widespread changes like that to all computers on our domain if it's the expected default setting!

 

https://learn.microsoft.com/en-us/answers/questions/952516/closing-ntfs-security-holes-in-windows-10

Edited September 1, 2023 by flyinghaggis