Is chroot the only protection against a hostile process?

lclarkmichalek · on March 24, 2015

Chroot (grsecurity makes this a lot better), the various namespaces, syslinux, seccomp.

Seccomp has strict mode, which allows you to say to the kernel "from this point on, allow me to only do read, write (to fd's I already have opened), _exit and sigreturn, otherwise kill the program". It's not perfect, but it reduces the vunrel space a lot.

You can also do a lot more fancy stuff, using the seccomp BPF interface (which I'm totally not writing a Haskell DSL for right now :D)

doomrobo · on March 24, 2015

Pretty much. There's always the option of putting it in a container (using Docker, for instance) or VM but chroot is probably the most commonly used and has the least overhead.

ncza · on March 24, 2015

Docker is not a security thing!

doomrobo · on March 25, 2015

I hear this refrain a lot but I never really understood it. Could you explain? I would personally feel much more comfortable running a process as a unique user in an fresh Ubuntu container than running it in a chroot. One needn't go far to find a huge number of chroot escape methods.

walterbell · on March 25, 2015

https://news.ycombinator.com/item?id=8107450

walterbell · on March 24, 2015

In this OS, are chroots enough to "withstand zero-day attacks in userspace", e.g. in combination with other hardening features?

_3u10 · on March 24, 2015

Yes, the lack of a network stack prevents the most common attacks, and drastically reduces the usefulness of gaining control of the system.

unwind · on March 24, 2015

I had to look up "zero-day attack", but it really meant what I thought it did, i.e. a previously unreported ("fresh") exploit (http://en.wikipedia.org/wiki/Zero-day_attack).

I don't understand this usage, which makes it sound as if zero-day attacks are a technical term, a category of attacks. Can anyone clarify?

walterbell · on March 25, 2015

It's more of a business term, e.g. http://en.wikipedia.org/wiki/Vupen