6 ms·

I've had the same sentiment for many years... Linux is indeed a miracle. But after spending a lot of time with it recently (e.g. getting LXC running last night

by chubot 14y ago

I've had the same sentiment for many years... Linux is indeed a miracle. But after spending a lot of time with it recently (e.g. getting LXC running last night), I've concluded that it would be very hard to design a system with a security API that is worse than Linux. The issue is that Linus doesn't design ANYTHING. He doesn't believe in design; he only believes in evolution. Unix was designed, whereas Linux is mostly a bunch of code bolted on top of Unix. It's not sustainable in the long term. Someone needs to actually design something eventually, so there is a stable base for more evolution. Spend some time looking through these: - traditional Unix ACL-based security - traditional resource limits - chroot (not secure, but used as a "part" of many security solutions) - capabilities - seccomp - LSM-based - SELinux - AppArmor - ... - LXC - cgroups - namespaces (apparently completed with this kernel release) - LXC user space tools - ptrace sandboxing - (at least a dozen projects use this) - user mode linux And you'll realize it's just a huge mess. I'm sure the complexity makes Linux measurably more insecure in practice. Or it just provides employment for a lot of people -- who knows. There's never going to be a way to clean this all up, since people are relying on all of it. I don't have that much experience with the alternatives; I'm sure they're messy in their own right. (I've used many OSes, but not security-wise.) But this definitely has me looking towards FreeBSD and such. Too bad it is more expensive on EC2. I mentioned Minix 3 here before -- it's probably a pipe dream, but being a microkernel, it seems like a good basis for a future secure Unix. It actually was designed in some sense. From what I gather people take the existence of root escalation exploits on Linux for granted. If that weren't so (and it shouldn't be with a microkernel), then traditional Unix security might actually cover a lot of cases that all these hacks on top are patching up. EDIT: Also, Linux should look to DJB for guidance. Out of all the hairiniess, how do you even do this on Linux (or any Unix)? http://cr.yp.to/unix/disablenetwork.html http://cr.yp.to/unix/disablenetwork.html It just seems crazy.

bcantrill 14y ago
With the disclaimer that I very much have a dog in the fight, you might want to look at illumos[1] and its distributions like SmartOS[2] and OmniOS[3]. It has a secure, robust container model (with a hat tip to FreeBSD jails for providing inspiration over a decade ago) and a mature least-privilege model that minimizes attack surface -- not to mention ZFS, DTrace, KVM and other goodies. At the very least, you can take solace in knowing that others share your desire for cleaner alternatives... [1] http://smartos.org/2011/12/15/fork-yeah-the-rise-and-development-of-illumos-2/ http://smartos.org/2011/12/15/fork-yeah-the-rise-and-develop... [2] http://smartos.org/ http://smartos.org/ [3] http://omnios.omniti.com/ http://omnios.omniti.com/
- chubot 14y ago
  Thanks for the links; I had heard of SmartOS but not known much about the technology. What sort of disappointed me about LXC is that you end up with an init process and 7 or 8 children of it in each container. I am more interested in sandboxing at the level of a single process. In a lot of cases you just want to run somebody else's Python code and look at its stdout; you don't need to spin up init and family do that. There are a hundred and one projects like this but most of them seem half-baked. Capsicum [1] looks like what I'm interested in; there seemed to be effort around a Linux port a couple years ago but I don't think it happened. Does Illumos/SmartOS provide anything like this? http://www.cl.cam.ac.uk/research/security/capsicum/ http://www.cl.cam.ac.uk/research/security/capsicum/
  - justincormack 14y ago
    You don't need init in each container, and the encouraged model of having a whole distro in a container is bonkers. Play around with clone(2)/unshare(2) directly, and it is fairly simple. All you need to know about pid 1 is if it terminates your namespace goes, and orphan processes will reparent to it (and some signals are blocked). If you have a single process then this doesn't matter really. You can do all this from Python I expect, I have done it all from Lua with no issues.
    - chubot 14y ago
      OK from what I understand "LXC" is basically the user space tools that give you the distro in the container... it's more of a VM model. But yeah I think I just need the underlying cgroups, and possibly some of the namespaces. Although I don't car aell that much if untrusted code can see what processes are running; just as long as it can't affect them. Just curious what you were using containers for from Lua? Sounds interesting.
      - justincormack 14y ago
        I started using them largely for testing netlink code, as it is much easier to create some isolated network devices than risk messing about with the real ones. This is part of a fairly comprehensive Linux binding for Lua https://github.com/justincormack/ljsyscall https://github.com/justincormack/ljsyscall
zokier 14y ago
Have you read Spenders (the grsec maintainer) recent comments on Linux security development practices? They provided interesting insight imho, even if they were bit flame-y. https://lwn.net/Articles/538221/ https://lwn.net/Articles/538221/ (ctrl-f spender)
justincormack 14y ago
For disable network as linked, the new seccomp mechanism is probably what you need, as you can blacklist socket system calls (or better whitelist). But it is pretty new.
pilgrim689 14y ago
"it seems like a good basis for a future secure Unix" There's QNX for that: http://www.qnx.com/products/neutrino-rtos/secure-kernel.html http://www.qnx.com/products/neutrino-rtos/secure-kernel.html It's used in industries such as automotive, nuclear, etc. Perhaps you meant "future secure open-source Unix" ;) (QNX source was closed the day RIM announced the purchase)
- beagle3 14y ago
  Was it ever open? Can you give a link to the last open version if it was?
FooBarWidget 14y ago
Unix was designed? You wish. The very early parts of Unix were designed, but pretty much everything after that was bolted on under the banner of "worse is better". Read about the currently decades old POSIX TTY subsystem to see how bad it is: http://www.linusakesson.net/programming/tty/ http://www.linusakesson.net/programming/tty/ ioctls and fcntl? Quick hacks to make things work. Fcntl lock files? Insane semantics that were quickly hacked on. Etc etc.

by chubot 14y ago

bcantrill 14y ago

With the disclaimer that I very much have a dog in the fight, you might want to look at illumos[1] and its distributions like SmartOS[2] and OmniOS[3]. It has a secure, robust container model (with a hat tip to FreeBSD jails for providing inspiration over a decade ago) and a mature least-privilege model that minimizes attack surface -- not to mention ZFS, DTrace, KVM and other goodies. At the very least, you can take solace in knowing that others share your desire for cleaner alternatives... [1] http://smartos.org/2011/12/15/fork-yeah-the-rise-and-development-of-illumos-2/ http://smartos.org/2011/12/15/fork-yeah-the-rise-and-develop... [2] http://smartos.org/ http://smartos.org/ [3] http://omnios.omniti.com/ http://omnios.omniti.com/

chubot 14y ago
Thanks for the links; I had heard of SmartOS but not known much about the technology. What sort of disappointed me about LXC is that you end up with an init process and 7 or 8 children of it in each container. I am more interested in sandboxing at the level of a single process. In a lot of cases you just want to run somebody else's Python code and look at its stdout; you don't need to spin up init and family do that. There are a hundred and one projects like this but most of them seem half-baked. Capsicum [1] looks like what I'm interested in; there seemed to be effort around a Linux port a couple years ago but I don't think it happened. Does Illumos/SmartOS provide anything like this? http://www.cl.cam.ac.uk/research/security/capsicum/ http://www.cl.cam.ac.uk/research/security/capsicum/
- justincormack 14y ago
  You don't need init in each container, and the encouraged model of having a whole distro in a container is bonkers. Play around with clone(2)/unshare(2) directly, and it is fairly simple. All you need to know about pid 1 is if it terminates your namespace goes, and orphan processes will reparent to it (and some signals are blocked). If you have a single process then this doesn't matter really. You can do all this from Python I expect, I have done it all from Lua with no issues.
  - chubot 14y ago
    OK from what I understand "LXC" is basically the user space tools that give you the distro in the container... it's more of a VM model. But yeah I think I just need the underlying cgroups, and possibly some of the namespaces. Although I don't car aell that much if untrusted code can see what processes are running; just as long as it can't affect them. Just curious what you were using containers for from Lua? Sounds interesting.
    - justincormack 14y ago
      I started using them largely for testing netlink code, as it is much easier to create some isolated network devices than risk messing about with the real ones. This is part of a fairly comprehensive Linux binding for Lua https://github.com/justincormack/ljsyscall https://github.com/justincormack/ljsyscall

zokier 14y ago

Have you read Spenders (the grsec maintainer) recent comments on Linux security development practices? They provided interesting insight imho, even if they were bit flame-y. https://lwn.net/Articles/538221/ https://lwn.net/Articles/538221/ (ctrl-f spender)

justincormack 14y ago

For disable network as linked, the new seccomp mechanism is probably what you need, as you can blacklist socket system calls (or better whitelist). But it is pretty new.

pilgrim689 14y ago

"it seems like a good basis for a future secure Unix" There's QNX for that: http://www.qnx.com/products/neutrino-rtos/secure-kernel.html http://www.qnx.com/products/neutrino-rtos/secure-kernel.html It's used in industries such as automotive, nuclear, etc. Perhaps you meant "future secure open-source Unix" ;) (QNX source was closed the day RIM announced the purchase)

beagle3 14y ago
Was it ever open? Can you give a link to the last open version if it was?

FooBarWidget 14y ago

Unix was designed? You wish. The very early parts of Unix were designed, but pretty much everything after that was bolted on under the banner of "worse is better". Read about the currently decades old POSIX TTY subsystem to see how bad it is: http://www.linusakesson.net/programming/tty/ http://www.linusakesson.net/programming/tty/ ioctls and fcntl? Quick hacks to make things work. Fcntl lock files? Insane semantics that were quickly hacked on. Etc etc.