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

Running as actual root in a VM would be my preferred design. There are lots of times a user might need to apt-get some dependencies for their compile job. Let an attacker do whatever they like in the VM. Then delete the VM between users.

Docker containers aren't really a good security barrier, and a VM is much better (although VM escape vulnerabilities aren't unheard of).

There are many ways a hostile program inside a VM can escape it and run code on the host or, at least, negatively affect it.

Please do share how can one escape qemu.

At your service:

https://www.techrepublic.com/article/vm-escape-flaw-in-qemu-...

Beautiful! Thank you.

> I did not see any relevant content on the websites you mention in your HN profile

At least I have a filled out profile, unlike you.

Besides that, and the cheap personal attacks, you seem to be completely missing the point so let me spell it out for you: VMs, containers, chroot jails and all those other tools with which we can try to isolate two pieces of software running on the same hardware all have exploits, past, current and future ones. Any piece of software of even moderate complexity will have bugs, any isolation method should be considered fallible and leaky and you best defenses will take that into consideration when architecting your setup.

If you don't then sooner or later someone with more patience, a larger budget or more knowledge than you will get the better of you with all the consequences that may have.

The idea is that virtualization escape vulnerabilities are quite frequent. An attacker might not have one on hand at any given moment and you might patch your system frequently when they become known.

But this only means a determinated attacker that has emulated root needs only patience. Good security always means stacked independent layers, betting the farm only on the guarantees of your VM is very unsafe.

I'm trying to understand what your point is, are you denying that there was a vulnerability?

As it stands it just sounds like you are just being a jerk on the internet.

I am asking for actual code that shows his statement is still true.

The statements I read as an answer to my question contain zero value and still lots of very unrelated words.

If you are sure there are vulns right now, please publish them. If not, shut up.

Nillywilly "computers might be insecure" is on a level I would not expect to read on a side like this one.

I just want to keep the quality level high for this news discussion site.

Can you please stop posting like this to HN? You've done this sort of haranguing a lot and it's not in the spirit of this site:

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

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

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

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

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

Please review the guidelines: https://news.ycombinator.com/newsguidelines.html. Note that they include: "Have curious conversation; don't cross-examine."

Running in a VM is good. Running in a VM as a non-priv user is better. Ideally you'd want multiple layers of defense in case of undiscovered gaps, human error and 0-days.

Not many if its Qubes OS.

One would be quite enough.

In fact, Qubes is using hardware virtualization IOMMU/VT-d [0], which has been escaped only once in 2006 by the project founder [1].

[0] https://www.qubes-os.org/doc/architecture/

[1] https://en.wikipedia.org/wiki/Blue_Pill_(software)

I trust Joanna Rutkowska's competence, but I wouldn't bet too much on chip makers not messing up again in the future.

It will be progressively harder, but it will happen.

I don't know much containerization outside of docker, but you can definitely apt-get some dependencies even inside docker containers.

Inside a docker container, you are root, so you can apt-get.

If it was in a typical container there'd be no hashed password for root, though. Just a ! or *.

In fact that's kinda the standard practice anyway nowadays (disallow logging in directly as root), so I'm really not sure what these guys are doing.

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

> More accurately, it seems the system treats them like empty files.

The reason is that the content is generated by a callback that the kernel calls, and the kernel does not want the content to be generated just in order to stat(2) the file, so it shows a zero length, and assumes that things like /bin/cat will just read(2) until EOF is returned, without trying to be too smart.

> Yes. Why wouldn't it be sandboxed?!

Famous last words.

If that was my server I would of course put a joke in /etc/shadow - did you try to brute force the hashes? It would not be a great surprise to find some obvious funny content if you try?

That'd be pretty funny :D

Like for example, if the entry for root in the joke /etc/shadow was the hash of "Thank you Mario! But our princess is in another castle!"

That's a pretty long passphrase, so someone would have to have put it in the word list directly to ever guess something that long. Would be fun though.

How many of your servers actually have jokes in /etc/shadow?

only the shadow knows

How many systems have you ran into with world readable /etc/shadow?