28

On a *nix system I can use a chroot to isolate two processes from each other and from the rest of the system. Is there any similar security system under windows? Or is there any way to prevent two processes from reading/writing to each others files?

Rook
  • 2,615
  • 5
  • 26
  • 34
  • 1
    I'm not sure the security tag is warranted here. http://kerneltrap.org/Linux/Abusing_chroot – MDMarra Jul 18 '10 at 16:54
  • @MarkM So you would say that a chroot isn't a security system? Also, that attack doesn't work on a grsecurity chroot (http://www.grsecurity.net/). – Rook Jul 18 '10 at 17:50
  • 1
    @The Rook - In that kerneltrap discussion, kernel devs discuss the fact that chroot was never intended to be a security device/ – MDMarra Jul 18 '10 at 18:12
  • @MarkM Interesting, but with the grsecuirty improvements the only method of breaking out would be to rip a hole into kernel land, which could be done buffer overflow in linux (or whatever kernel you are using). – Rook Jul 18 '10 at 18:35
  • 1
    @The Rook - Right, I was simply saying that you may want to rephrase the question. There have been extensions to chroot or spins on the concept (like jails) that have been designed with security in mind. In your post, you refer to chroot as a security device, which it was never intended to be. – MDMarra Jul 18 '10 at 19:57
  • @The Rook and @MarkM At the end of the day, there is no sliver bullet for security. – Natalie Adams Jul 18 '10 at 20:49
  • 1
    @Nathan Adams I agree, but "security in layers". – Rook Jul 18 '10 at 23:37
  • 1
    Looks like I've asked something fairly similar [here](http://serverfault.com/questions/507231/). Did you ever manage to set this up on Windows Server? The answer you accepted neither explains how to do this, nor says that it's not possible... – RomanSt May 13 '13 at 19:13
  • I'm joining @romkyns here -- OP, how did you solve this exactly? – dimitarvp Jan 23 '16 at 11:32

6 Answers6

8

Sandboxie http://www.sandboxie.com/

Not exactly like chroot. It does setup a sandbox for each program you specify. It can easily keep processes isolated.

Jason Berg
  • 18,954
  • 6
  • 38
  • 55
6

To solve this specific need (program assumes it's running off of a root directory), the SUBST command is probably what you want. It's a holdover from DOS, and still exists in windows 10.

the SUBST command will mount a directory as a new drive letter.

then you can run the software from the newly created drive, and it will think it's on your new drive S if you run it from that path.

5

I'm not sure you will gain anything on Windows by chrooting - do you have a specfic need?

In case any the top result on google is http://www.winquota.com/wj/.

Perhaps application virtualization might be an option? Microsoft has the following to say about it:

In a physical environment, every application depends on its OS for a range of services, including memory allocation, device drivers, and much more. Incompatibilities between an application and its operating system can be addressed by either server virtualization or presentation virtualization; but for incompatibilities between two applications installed on the same instance of an OS, you need Application Virtualization.

Tamás Szelei
  • 115
  • 1
  • 7
Jon Rhoades
  • 4,989
  • 3
  • 30
  • 47
  • 6
    One of my processes was poorly written and very insecure, management doesn't want to fix it because it would be "too expensive". I expect this process to get owned eventually and i want to limit the impact on my system. If you really believe there is nothing to gain, then you must read more about chroots. – Rook Jul 18 '10 at 17:49
  • 1
    @Rook Because on Windows you can have access rights divorced from filesystem layout. Your chestbeating in the comments section of [this answer](http://serverfault.com/a/638106/284663) aside, that is the approach most people take to insulate portions of the file system from a process that is not authorized to access it; simply give the user the process is started under access to the subset of the filesystem and services that it needs. – Asad Saeeduddin Feb 28 '16 at 02:36
  • 1
    @Asad Saeeduddin Speaking of filesystems, doesn't [windows just autorun untrusted executables found on a USB sticks](http://www.visualdesigning.com/articles/how-to-create-autorun-usb-drive/)? What year is it? – Rook Mar 01 '16 at 03:06
  • I have a specific need, not security-related -- this program I'm porting expects to operate on its own root filesystem, and it'd be a _massive_ effort to port it to use current directories correctly. Thankfully, it does work filesystem-independently -- on Windows, it'll just sprawl out across the root of whatever drive it's run on. If I could just "alias" the root dir in Windows to some subdirectory, it'd be much cleaner and easier to keep track of, hence wanting chroot. – Nic Nov 05 '19 at 04:11
5

I wouldn't use anything like this, you are running under Windows mate.

NTFS has the most fine grained access rights you can find. Its not hard to let a prozess start with lower privileged user, and only giving that user access to the files of this single application.

No need to use something like chroot, which is not a security tool, when you can already define what user is allowed to do what in what directory.

Its no different than like giving the Apache under Linux its own user, only allowed to work inside his folders.

Okay Dokey
  • 71
  • 1
  • 1
  • 2
    This is the correct answer as to why chroot isn't needed – Jim B Jan 05 '16 at 18:41
  • @rook, then they failed to follow the BPSAD and PTH whitepapers to eliminate golden ticket attacks. As far as I know that only still works on *nix based kerb. – Jim B Jan 05 '16 at 22:23
  • @Jim B compartmentalization may sound foreign in a platform that routinely grants administrative rights to the browser, database, and web server. however, sandboxes are a quint essential defense-in-depth measure irregardless of platform. – Rook Jan 05 '16 at 23:26
  • @rook, I think you are confusing rights with isolation, windows isolates processes by default. Processes can only access/integrate with or affect another process if it has permission. – Jim B Jan 06 '16 at 00:30
  • 1
    @JimB, I don't think (so unless I completely misunderstood your comment). Starting a process in Windows 7 for example gives you no security prompt and afterwards the process can read 90% of your storage drive without ever having to ask any system process about it. Only if it tries to modify, say "C:\Program Files" then the OS can slap its wrists but that's not security, that's fundamental essentials barely being covered. – dimitarvp Jan 23 '16 at 11:30
  • @dimitko , I don't think you understand how permissions work. No process can communicate with another process without permission, and no file can be accessed without perms. – Jim B Jan 24 '16 at 20:16
  • @JimB Last I checked, I could code one quick C++ program right now and make it modify Chrome's cache and it'll have zero problems screwing it up (or is that no longer the case?). I think we all agree Windows lacks proper isolation / sandboxing. – dimitarvp Jan 24 '16 at 20:21
  • Completely untrue, add a deny to the chrome cache dir for that user and you can't do anything. Sandboxing (like chroot in *nix) isn't there by default but is simply a matter of permissions, unless you've also given that user elevated rights. The simplest thing to do is stick a deny acl at the root of the drive and only allow what's required for the app. – Jim B Jan 24 '16 at 20:50
  • @Rook "platform that routinely grants administrative rights to the browser, database, and web server". The platform doesn't grant those rights, you do. If that's what you feel like doing, more power to you, don't blame it on Windows when you get pwned. – Asad Saeeduddin Feb 28 '16 at 02:35
  • 1
    @JimB: if you have to set a deny permission before a process is prohibited from accessing another process' files, then it isn't "isolated by default" as you claimed above. – Lie Ryan Apr 03 '16 at 09:48
  • @Lie Ryan , if like the OP you are not a windows admin, the hope is that file perms might be easier than user rights to grasp. By default processes are not granted rights, but the OP (in a comment) mentioned that he gave a process rights (calling it insecure), aside from the idea that chroot doesn't solve process elevation issues on Unix, on windows its the default stance. It's of course also possible to build a process with additional rights to cause that to not be true (agents for various apps are the usual culprit) and are a fantastic source of escalation attacks. – Jim B Apr 04 '16 at 02:58
  • @Jim B - "The simplest thing to do is stick a deny acl at the root of the drive and only allow what's required for the app." - Maybe I'm misunderstanding what an ACL is, but I ran into problems trying to figure our how to deny access to an entire drive without unintended side effects: https://superuser.com/questions/1623841 – Shawn Eary Feb 08 '21 at 15:27
  • I created a service account for a PowerShell GitLab Runner. I then gave that service account *no* permissions but it was *still* able to create files in unusual locations. My mentor didn't like that and I'm looking for a way to prevent that behavior without trashing the permissions for the entire C: drive. I shouldn't have to explicitly assign a *deny* at the root of the C: drive to prevent this behavior. The fact that Windows requires me to do this implies something is "broken by design". – Shawn Eary Feb 08 '21 at 15:38
3

There is a chroot.exe included in Gow (Gnu On Windows)

mozey
  • 151
  • 3
  • 1
    The one in Git Bash also seems to work but I think you have to be in an Git Bash prompt before calling it. – Shawn Eary Feb 08 '21 at 15:43
-2

If you are not uploading files from the website, simply create a read only ISO of your website and make that your root directory, then mount it.

Another solution is to use DISKPART and create a READONLY partition/drive with the webpages.

Hope this was useful.