No surprise, coming from Nix!
#include
21–30 of 132 posts
Re: #include </etc/shadow>
#22Compiling untrusted code is already a dangerous affair. Compilers are not audited for security vulnerabilities, and many versions of popular compilers have contained memory corruption bugs or similar issues that could be leveraged to gain code execution. Many services that compile untrusted code will run the resulting binaries too, which definitely requires a sandbox or disposable VM - at which point you may as well…
In a container or not, running a compiler-as-a-service as root is never the right way to run a compiler-as-a-service.
Re: #include </etc/shadow>
#23> Recently I saw a tweet where someone mentioned that you can include /dev/stdin in C code compiled with gcc. This is, to say the very least, surprising. Why is this surprising? Do programmers not read books anymore? Almost, any decent C programming book explains that #include reads the specified file and substitutes itself with the content of that file. Any Unix/Linux book explains that /dev/stdin is a special devic…
It used to be the case that programmers were simply another step up from "power user", and as such would've already become familiar with such aspects of the system. Now, people are "learning to code" with barely any basic computer literacy, and the situation is even worse thanks to opaque locked-down platforms like mobile, so that a lot of them unfortunately have only a vague notion of what a file is, much less the whole "devices are also files" paradigm that underlies Unix (and to a certain extent, Windows --- but how many Windows programmers know about CON?)
I've surprised some coworkers -- ones who are definitely not inexperienced or just learning -- by e.g. using /dev/stdout as a logfile, or even /dev/pts/x to have multiple logs directly written to separate terminal windows. They all "knew" that devices are files, but never thought about actually trying to use them as such.
Re: #include </etc/shadow>
#24Earlier quoted context omitted.
> I find it more likely that the "root" user mentioned in this post is the root user of some disposable Docker container, which would be the right way to run a compiler-as-a-service. My understanding is that Docker isn't something you use if you really want security.
You're being downvoted but you're right- Docker really isn't a good choice for running untrusted and potentially hostile code, since a container breakout zero-day pretty much immediately compromises the host OS. (Even with user namespace remapping a breakout still gives enough access to get up to shenanigans.) At the minimum a disposable VM using something like KVM/QEMU/Firecracker would be a start. That way you have…
Can you elaborate? Doesn't a KVM bug result in pretty much the same thing? Or is the argument that this is less likely?
Re: #include </etc/shadow>
#25Virtually all Linux distributions sandbox their package build system using something like fakeroot.
Before the security reason the OP mentions, they don't want to screw the build tasks because of the host environment they are running on, or they don't want to screw the host directories when they make mistakes with installation paths.
Re: #include </etc/shadow>
#26Earlier quoted context omitted.
You're being downvoted but you're right- Docker really isn't a good choice for running untrusted and potentially hostile code, since a container breakout zero-day pretty much immediately compromises the host OS. (Even with user namespace remapping a breakout still gives enough access to get up to shenanigans.) At the minimum a disposable VM using something like KVM/QEMU/Firecracker would be a start. That way you have…
Can you elaborate? Doesn't a KVM bug result in pretty much the same thing? Or is the argument that this is less likely?
The attack surface of a container is massive.
The attack surface of a hypervisor is tiny, in comparison.
There was 'interesting' research out of IBM a couple of years ago where they claimed they found that containers with good seccomp profiles etc were 'as secure as' a VM. Well, nobody goes around believing that.
I recall once asking Joanna Rutkowska this same question, I think just days after she had outlined some pretty glaring security issues in the Xen hypervisor. She pointed out that if we were finding (and fixing) security issues in the 2K (or 20K, or however big the trusted-computing-base of Xen is, I forget) then imagine the number of issues laying unfound in your modern kernel...?
Re: #include </etc/shadow>
#27This seems contrived. So you need to send someone "evil" code that they won't read, have them compile it as root, and then ship you the resulting binary. I wouldn't read too much into it "working" with some kind of compile/show service, as they could have been using non-persistent containers. Ultimately this seems like social engineering i.e. "Tricking privileged users into doing as root." Might have well ask them to…
Going off on a tangent, but programmers (who ought know better) are pretty poor about running untrusted code, even today.
This was the top of HN just the other day: https://news.ycombinator.com/item?id=21741504
The money quote is at the end: "Docker is the new ‘curl | sudo bash‘"
Re: #include </etc/shadow>
#28Compiling untrusted code is already a dangerous affair. Compilers are not audited for security vulnerabilities, and many versions of popular compilers have contained memory corruption bugs or similar issues that could be leveraged to gain code execution. Many services that compile untrusted code will run the resulting binaries too, which definitely requires a sandbox or disposable VM - at which point you may as well…
> I find it more likely that the "root" user mentioned in this post is the root user of some disposable Docker container, which would be the right way to run a compiler-as-a-service. My understanding is that Docker isn't something you use if you really want security.
This is true, but containers are so much better than nothing and relatively simple to use, so if someone isn't going to put in the effort for a more secure solution I'd rather they use Docker than nothing.
Re: #include </etc/shadow>
#29Earlier quoted context omitted.
> I find it more likely that the "root" user mentioned in this post is the root user of some disposable Docker container, which would be the right way to run a compiler-as-a-service. My understanding is that Docker isn't something you use if you really want security.
You're being downvoted but you're right- Docker really isn't a good choice for running untrusted and potentially hostile code, since a container breakout zero-day pretty much immediately compromises the host OS. (Even with user namespace remapping a breakout still gives enough access to get up to shenanigans.) At the minimum a disposable VM using something like KVM/QEMU/Firecracker would be a start. That way you have…
I think I you run it without --privileged and userns enabled it's not that bad, since at least the processes run with an unprivileged user.
Re: #include </etc/shadow>
#30Its interesting tangent that the "confused deputy" security problem was first identified in a compiler, back in the days when people paid to have their code compiled. This led towards "capabilities" and lots of operating system design that is now in vogue again.
https://en.wikipedia.org/wiki/Confused_deputy_problem
(this #include problem can be thought of as a confused deputy vulnerability. The compiler shouldn't have the capability to read the password file, and if it did, it is a confused deputy to be wielding that cap on behalf of its user, instead of wielding the caps it gets from the user).
Its sad that the links to Norm Hardy's original write-up all seem broken.
https://web.archive.org/web/20031205034929/http://www.cis.up...
Norm was a brilliant mind. He was talking and thinking about capabilities right up until the end.