Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

#include

blog.hboeck.de

Post reply on HN
Print view View original

41–50 of 132 posts

Re: #include </etc/shadow>

#41

Post by codedokode »

dharmab wrote: post #16
mehrdadn wrote: post #13

Earlier 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…

Docker was not made for security, and this is explicitly documented in its manual.

Also, you don't need VM, just playing with namespaces, chroots and syscall filters should be enough. VMs are very ineffective and complicated.

Re: #include </etc/shadow>

#42

Post by simias »

zonidjan wrote: post #39

> 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. You can also call something to read from stdin in your Makefile, or read from stdin in your executable. > But is it equally obvious that the compiler also needs to be sandboxed? Yes. Why wouldn't it be sandboxed?! > I even found one service that ... showed me the ha…

>That's quite a leap from 'I can read /etc/shadow' to 'I am root'.

Is it? There are alternatives of course but I would say that without further clues that seems the most likely explanation.

I agree with the rest of your points though. In general it seems fairly obvious that build systems should be sandboxed if they're building "foreign" code, after all if you can mess with the source code you can probably affect the build system as well, and from there you can basically do anything you want.

Re: #include </etc/shadow>

#43

Post by merb »

dharmab wrote: post #16
mehrdadn wrote: post #13

Earlier 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…

actually when it is a docker container running with gvisor, it is a real sandbox. without it, it definitv isn't. (https://gvisor.dev/)

Re: #include </etc/shadow>

#44

Post by tinus_hn »

Someone1234 wrote: post #4

This 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…

There are many services that you can just send code to and they will automatically compile it.

Re: #include </etc/shadow>

#45

Post by t0astbread »

thenewnewguy wrote: post #28
mehrdadn wrote: post #13

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

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.

Are containers simpler to automate from a service provider's POV than, say KVM or qemu or Firecracker (or other VM tech)?

Re: #include </etc/shadow>

#46

Post by pdpi »

codedokode wrote: post #41
dharmab wrote: post #16

Earlier 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…

Docker was not made for security, and this is explicitly documented in its manual. Also, you don't need VM, just playing with namespaces, chroots and syscall filters should be enough. VMs are very ineffective and complicated.

Funny you say the docker is not for security (it’s there in the manual) but then suggest chroot of all things — that is just as well documented as not being meant for security!

Re: #include </etc/shadow>

#47

Post by goatinaboat »

Someone1234 wrote: post #4

This 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…

So you need to send someone "evil" code that they won't read, have them compile it as root

That’s easy, people do curl|sudo bash all the time these days.

Re: #include </etc/shadow>

#48

Post by draw_down »

mkl wrote: post #38
pvtmert wrote: post #33

- most of them (actually) containers - one can easily do: ``` char buf[8192]; fread(buf, sizeof(buf), 1, fopen("/etc/shadow", "rb")); printf(buf); ``` also reading 'shadow' is not do that much since its salted and hashed. strong password (10 chars) will take many months and years. you can do more harm with actual 'code' which you may compile on the service

> one can easily do: > char buf[8192]; fread(buf, sizeof(buf), 1, fopen("/etc/shadow", "rb")); printf(buf); The code is compiled on the server, but it doesn't run there.

Where do you suppose it runs, then?

Re: #include </etc/shadow>

#49

Post by himinlomax »

zonidjan wrote: post #39

> 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. You can also call something to read from stdin in your Makefile, or read from stdin in your executable. > But is it equally obvious that the compiler also needs to be sandboxed? Yes. Why wouldn't it be sandboxed?! > I even found one service that ... showed me the ha…

> That's quite a leap from 'I can read /etc/shadow' to 'I am root'.

Of all the leaps in that post, that's the least leapy thing. `shadow` exists precisely so that only `root` can read its content, whereas before said content resided in `passwd` which _needs_ to be readable by all.

I see only two possibilities here. Either the people who set up that compile service are complete morons and run said compile as actual root in an actual VM; OR, more likely, shit runs in a container with an _apparent_ id of 0 but no actual privilege outside its temporary environment.

Re: #include </etc/shadow>

#50

Post by cesarb »

kbumsik wrote: post #25

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

fakeroot is not a sandbox, it's just a way to have tasks which normally expect to run as root (like setting file permissions during "make install", or creating a .tar.gz with the correct permissions) work without root. IIRC, it works through LD_PRELOAD, and it's very easy to bypass (just unset that environment variable).
Post reply on HN