[HN Gopher] Unprivileged Chroot()
___________________________________________________________________
Unprivileged Chroot()
Author : rwmj
Score : 52 points
Date : 2021-03-18 10:52 UTC (12 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| kortex wrote:
| This just feels like law of unintended consequences waiting to
| happen. Like the use cases are super cool, like using it with
| FUSE to basically redirect a file system view. But it feels like
| asking for trouble. You would need to know the interaction
| between all manner of systems that could be used to effect an
| escalation.
| whizzter wrote:
| One thing i wonder about when reading about the issues of chroot
| is why they just didn't make "PR_SET_NO_NEW_PRIVS" default of
| chroot from the beginning and make other ways to strengthen
| chroot security (because it was after all intended to provide
| security so why did backwards compatibility trump security?)
| st_goliath wrote:
| PR_SET_NO_NEW_PRIVS was added in Linux 3.5
|
| chroot() is from ancient Unix/BSD times and was in Linux since
| pretty much the beginning of Linux.
|
| Changing its behavior after the fact would break expected
| behavior of existing programs AND would break compatibility
| with other Unixen.
| totetsu wrote:
| Unixen, is that german?
| chasil wrote:
| If the Linux kernel does not implement chroot as described
| below, then it cannot claim to be POSIX-compliant.
|
| Going out of compliance will come at some cost.
|
| https://pubs.opengroup.org/onlinepubs/7908799/xsh/chroot.htm...
| tinus_hn wrote:
| I think Linux explicitly claims not to be POSIX compliant
| because you have to pay for that.
| chasil wrote:
| This is what the wiki says. I've never heard of Linux-FT,
| but I did remember that someone took the certification
| process all the way.
|
| Linux systems adhere to POSIX,[81] SUS,[82] LSB, ISO, and
| ANSI standards where possible, although to date only one
| Linux distribution has been POSIX.1 certified, Linux-
| FT.[83][84]
|
| https://en.wikipedia.org/wiki/Linux
|
| Archive.org has the supporting documents.
|
| https://web.archive.org/web/20160404122450/http://www.linux
| j...
|
| "Unifix GmbH (Braunschweig, Germany) developed a Linux
| system that has been certified to conform to FIPS 151-2 (a
| superset of POSIX.1). This technology was available in
| Unifix' own distribution called Unifix Linux 2.0 and in
| Lasermoon's Linux-FT."
|
| https://web.archive.org/web/20111010111215/http://www.debia
| n...
| dathinab wrote:
| Historic reasons (like chroot being older etc.).
|
| But I believe the appropriate solution would be either:
|
| - a prctrl like PR_SET_RESTRICED_CHROOT which will "degrade"
| CAP_SYS_CHROOT to require all the thinks listed (but still
| requires CAP_SYS_CHROOT).
|
| - a new capability like CAP_SYS_RESTRICTED_CHROOT (probably not
| an option).
|
| The current patch would weakening the security sandbox of _any_
| process dropping CAP_SYS_CHROOT which IMHO is unacceptable
| given that PR_SET_NO_NEW_PRIVS is known as being imperfect.
| Denvercoder9 wrote:
| There's plenty of uses of chroot outside security (i.e.
| bootstrapping or troubleshooting a broken system), and Linux
| doesn't break userspace. Ever.
| Ericson2314 wrote:
| Ahh.... we just need Capsicum/CloudABI for real to end the
| badness. Security and expressive power one can actually
| understand.
| georgyo wrote:
| Can't unshare essentially do the same thing?
|
| unshare --map-current-user --root=<new root> <program>
|
| And works completely unprivileged using namespaces.
| raimue wrote:
| Be aware that on some distributions such as Debian or RHEL,
| user namespaces are restricted by default and cannot be used
| like this from unprivileged user accounts. Although Debian is
| going to change the default with the next release.
|
| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446
| zimbatm wrote:
| If those distros are paranoid about the security implications
| of user namespaces, then they would certainly apply that
| reasoning to user chroot.
| georgyo wrote:
| Interesting.
|
| Still, as namespaces gain more and more traction, the value
| of adding rootless chroot goes down.
| zokier wrote:
| unshare calls chroot behind the scenes:
| https://git.kernel.org/pub/scm/utils/util-linux/util-linux.g...
| CyberRabbi wrote:
| Yes but it does so as the root user in the new user
| namespace, which is allowed according to existing rules. The
| change in question is about not requiring root in any user
| namespace.
| georgyo wrote:
| Thanks for the link!
|
| In that case, it seems completely arbitrary to not make
| chroot work as a normal user then.
| knorker wrote:
| Why not use unveil() (From OpenBSD) for this use case?
| shawnz wrote:
| That doesn't let you construct an arbitrarily structured
| virtualized filesystem like chroot does, just hide parts of the
| existing filesystem
| knorker wrote:
| Yes, but wasn't the use case to reduce access, not to fake a
| new root?
| shawnz wrote:
| The use case is isolation, which is not necessarily exactly
| the same as reducing access.
|
| For example, maybe you don't want the process to be able to
| easily detect that it has had its access reduced, by
| simulating a full-access environment.
|
| Or for example, maybe you don't care about access at all
| and you just want to avoid conflicts between two processes
| by giving them separated namespaces for their data.
| gbrown_ wrote:
| Can you elaborate on this please? I'd consider unveil to be
| far more capable of creating "an arbitrarily structured
| virtualized filesystem" view than chroot. I'd also invert the
| thinking of "just hide parts of the existing filesystem" as
| it whitelists paths and access rather than blacklisting.
| ori_b wrote:
| How do you bind a /tmp/empty to /home/$USER with unveil, so
| that you can see and capture the files some program
| creates?
| gbrown_ wrote:
| Sorry I don't quite grok your comment. It sounds like a
| bind mount so I'm unsure how it relates to unveil or
| chroot?
| ori_b wrote:
| Chroot is more or less a bind mount over /. Bind mounts
| generalize chroot. Unveil does not, and therefore does
| not allow you to provide arbitrary views of the file
| system.
|
| It's useful for other reasons. On OpenBSD, a full web
| browser compromise does not lead to full file system
| access.
| shawnz wrote:
| Unveil has no way to change the existing structure of the
| filesystem. With chroot it's easy: create the structure you
| want in a subdirectory and then chroot into it
| gbrown_ wrote:
| If changing a process root directory is really what you
| want to do then yes chroot is the right tool for the job.
| But from a perspective of "jailing" daemons as mentioned
| in the article I think unveil is a better API.
|
| I'm not sure what pieces of software populate directories
| and then chroot into them aside from maybe some build
| systems? But those likely create or bind in some /dev and
| /proc pieces which would be privileged operations anyway.
| And in such a case would containers not have surplanted
| chroot?
| shawnz wrote:
| "Jailing" isn't necessarily just about security, but
| isolation in general. Unveil would be a stronger tool if
| the concern is strictly security, but also there's no
| reason they couldn't both be used.
|
| Chroot is itself sometimes used to provide container-
| style functionality, so I think it's wrong to say
| containers "surplanted" it.
| zokier wrote:
| > And in such a case would containers not have surplanted
| chroot?
|
| Containers use chroot
| Blikkentrekker wrote:
| > _If these conditions are met, it is argued, it is safe to allow
| a process to call chroot()._
|
| It is safe only insofar some other software with elevated
| privileges whose security model assumes that only root can
| chroot, not run.
|
| This is an issue with security that is had to avoid; some
| software is written on the assumption that certain things are
| impossible that may become possible in the future.
|
| It is also why most capabilities are in practice useless as a
| tool of granularity on the average system and that all
| capabilities can often be constructed from a subset that is often
| as large as a single one, as so much software was written and
| designed before such capabilities existed, under the assumption
| that, if one have one, one have all.
| rwmj wrote:
| I'm intrigued to know if Microsoft (where the patch submitter
| works) have a use case for this or if it's related to one of his
| other security projects (see http://digikod.net/). I think it
| needs a strong motivating case.
| chasil wrote:
| Microsoft OpenSSH is at least faking it. 4084
| 2021-03-02 01:08:24.055 fatal: safely_chroot:
| stat("C:\\sftpjail"): No such file or directory
| You-Are-Right wrote:
| Why you write "Microsoft" and "Security" in one sentence?
| PeterisP wrote:
| For me personally a potential application seems to be embedding
| general purpose languages as scripting tools within
| nonprivileged applications; such a chroot would make it easier
| for the app to grant some filesystem access to a potentially
| malicious script without trying to restrict the language, API
| and libraries used for that.
| remexre wrote:
| Why not use a mount namespace? And how are you creating a
| /dev without root?
| southerntofu wrote:
| Maybe chroot is not the right solution, but having unprivileged
| containers/jails natively supported (not docker/systemd-
| containerd overlay) sounds useful.
| dathinab wrote:
| My reaction:
|
| Why? Oh that makes sense. Wait! Abysmal Security Nightmare!
| Nooooooo Don't do that, Pleeeeeeease.
|
| One of the main reason is that:
|
| 1. It increases the attack surface.
|
| 2. At least currently PR_SET_NO_NEW_PRIVS must not be relied on
| to be perfect for security. Must use cases use it as an
| additional security layer, but the chroot patch uses it as a
| fundamental required to be perfect building block.
|
| 3. As far as I can tell the benefit it gives is not worth the
| increased attack surface even if PR_SET_NO_NEW_PRIVS would work
| perfectly. But I might be wrong.
|
| Honestly the additional constraints it puts on chroot are good
| and I believe should be fulfilled for must use cases of chroot.
| So I think best would be either a "CAP_RESTRICTED_CHROOT"
| capability which allows chroot but only under given circumstances
| or a prctrl which "degrades" CAP_SYS_CHROOT to only work under
| given circumstances.
|
| In both cases programs which drop all CAP's they don't need would
| not be affected by this feature made for programs which use
| chroot.
|
| But in the current design the sandbox of ALL!!!! sandboxed
| programs which drop the CAP_SYS_CHROOT capability is weakened.
| Which IMHO is unreasonable.
___________________________________________________________________
(page generated 2021-03-18 23:02 UTC)