4 ms·

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 mak

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 6y ago
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 6y ago
  Unixen, is that german?
  - st_goliath 6y ago
    Interesting. According to the German Wiktionary, yes. Back in high school (in Austria, speaking German) I've been told several times by a Unix grey beard I had as a teacher that "Unixen" is the preferred plural of Unix, similar to "VAXen" for VAX, which the English Wiktionary does seem to know about.
- whizzter 6y ago
  Yes, it'd break compatibility, but mostly compatibility of components added after chroot if I'm not mistaken? Would escaping chroot and/or rooting by tampering with /bin/su(-do) have been possible on these older unices?
  - st_goliath 6y ago
    Those problems were known before Linux was a thing, which is part of the reasons only root was historically allowed to do a chroot(). Even Unix v7 insists on chroot() being only called by the root user (the chroot syscall is in /usr/sys/sys/sys4.c).
Denvercoder9 6y ago
There's plenty of uses of chroot outside security (i.e. bootstrapping or troubleshooting a broken system), and Linux doesn't break userspace. Ever.
- whizzter 6y ago
  Isn't it just the ABI and basic semantics that is never supposed to be broken? By extending that logic one could say that the kernel should never patch kernel exploits since it'd break things the exploits expects, naturally this is a silly hyperbole and i do understand that the line has to be drawn somewhere but chroot is old and imho additions that has enabled breaking out would have broken the original semantic. I do see the usage for bootstrapping and troubleshooting so that does cause an issue.
chasil 6y ago
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.html https://pubs.opengroup.org/onlinepubs/7908799/xsh/chroot.htm...
- tinus_hn 6y ago
  I think Linux explicitly claims not to be POSIX compliant because you have to pay for that.
  - chasil 6y ago
    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 https://en.wikipedia.org/wiki/Linux Archive.org has the supporting documents. https://web.archive.org/web/20160404122450/http://www.linuxjournal.com/article/0131 https://web.archive.org/web/20160404122450/http://www.linuxj... "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.debian.org/doc/FAQ/ch-compat.en.html https://web.archive.org/web/20111010111215/http://www.debian...
- whizzter 6y ago
  Nothing in that spec says anything about the process having the opurtunity to escalate privileges or escaping the chroot after invoking the call to chroot.
dathinab 6y ago
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.

st_goliath 6y ago

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 6y ago
Unixen, is that german?
- st_goliath 6y ago
  Interesting. According to the German Wiktionary, yes. Back in high school (in Austria, speaking German) I've been told several times by a Unix grey beard I had as a teacher that "Unixen" is the preferred plural of Unix, similar to "VAXen" for VAX, which the English Wiktionary does seem to know about.
whizzter 6y ago
Yes, it'd break compatibility, but mostly compatibility of components added after chroot if I'm not mistaken? Would escaping chroot and/or rooting by tampering with /bin/su(-do) have been possible on these older unices?
- st_goliath 6y ago
  Those problems were known before Linux was a thing, which is part of the reasons only root was historically allowed to do a chroot(). Even Unix v7 insists on chroot() being only called by the root user (the chroot syscall is in /usr/sys/sys/sys4.c).

Denvercoder9 6y ago

There's plenty of uses of chroot outside security (i.e. bootstrapping or troubleshooting a broken system), and Linux doesn't break userspace. Ever.

whizzter 6y ago
Isn't it just the ABI and basic semantics that is never supposed to be broken? By extending that logic one could say that the kernel should never patch kernel exploits since it'd break things the exploits expects, naturally this is a silly hyperbole and i do understand that the line has to be drawn somewhere but chroot is old and imho additions that has enabled breaking out would have broken the original semantic. I do see the usage for bootstrapping and troubleshooting so that does cause an issue.

chasil 6y ago

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.html https://pubs.opengroup.org/onlinepubs/7908799/xsh/chroot.htm...

tinus_hn 6y ago
I think Linux explicitly claims not to be POSIX compliant because you have to pay for that.
- chasil 6y ago
  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 https://en.wikipedia.org/wiki/Linux Archive.org has the supporting documents. https://web.archive.org/web/20160404122450/http://www.linuxjournal.com/article/0131 https://web.archive.org/web/20160404122450/http://www.linuxj... "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.debian.org/doc/FAQ/ch-compat.en.html https://web.archive.org/web/20111010111215/http://www.debian...
whizzter 6y ago
Nothing in that spec says anything about the process having the opurtunity to escalate privileges or escaping the chroot after invoking the call to chroot.

dathinab 6y ago

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.