Hacker News Reader

Comment by whizzter | Hacker News Reader

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?)

View on HN

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.

Unixen, is that german?

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.

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?

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).

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

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.

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...

I think Linux explicitly claims not to be POSIX compliant because you have to pay for that.

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.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...

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.

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.

Reply on news.ycombinator.com