Hacker News Reader

Comment by rrr_oh_man | Hacker News Reader

[flagged]

Everything is relative of course but it's a consensus view in OS literature that the Unix family of operating systems doesn't have strong security. There's a huge TCB in which bugs lead to vulnerabilities with high probability, as we see all the time.

This is why eg cloud providers don't rely on the OS to isolate customers from each other.

Since the reneissance of virtualization, many security focused systems have built on that, like Qubes OS, seL4-based virtualized systems, etc.

Everything in security is layers of defense against a threat model.

To design a secure system one must first ask who is going to attack it and with what forces.

Making truly secure systems is an art and is rarified ground.

What is using seL4-based virtualized systems? I am very interested in trying that out of the prices aren't for enterprise only.

Idk if it's "the Unix family". Clouds are running with SmartOS for example with containers running on bare metal and I've not heard of security issues with this model.

SmartOS is a fork of OpenSolaris right? Solaris used to have its share of public vulnerability discourse when it had more users, and it quieted down as the user base shrank and people stopped deploying it as a general purpouse server OS. In a slow moving niche OS I wouldn't put much weight on low volume of public security problem discourse especially in face of apparent architectural problems.

Yes it's a fork of OpenSolaris. Companies are running clouds with it, with containers of different clients running next to each other on bare metal (no VM to re-isolate). If it was so easy to exploit it would have been done already wouldn't it ?

No, absence of evidence is not evidence of absence, that's a very central thing to understand when thinking about software vulnerabilities.

It's not wrong. Linux does not have a great security track record, it was built on completely different security principles than the ones we have today. You can find public criticism from Theo de Raadt and grsecurity if you want to find out more.

It's a kernel that has served us well, especially considering its ubiquity, but it will never be a "secure" kernel.

I think it’s a shock when compared with the insecurity of Windows also forgetting that that was the reality on the ground in the 90s and that Windows also had a larger share. Windows has since hardened their security model and could be a more secure out of the box experience than Linux (eg shipping with TPM and FDE set up correctly).

But yeah, there’s plenty of things you’d do differently if you wanted to properly secure Linux. It just shows that economically that’s not the most important thing for companies using Linux.

I think you are confusing Linux the Kernel with Linux-based operating systems. The original quote from the README was referencing the kernel and made no comparison to Windows or the NT kernel.

The Linux kernel and distributions is what I’m talking about so yes compared with NT kernel and windows as a distribution.

The design choices you’d make to build a secure OS (kernel and user space) looks very different. The microkernel design is a more secure design but techniques to make it work fast took a very long time to develop (+ computer HW also got fast enough that the overhead is no longer as big of a deal + we have multithreading everywhere that microkernel can sometimes exploit more naturally).

There are heaps and heaps of security issues in Linux (the kernel).

Simply mounting a file system can result in your system being compromised if the file system was maliciously crafted. This isn't something that is actively protected against.

Another issue I can think of OTTOMH, is unprivileged user namespaces causing lots of security issues to surface because certain parts of the kernel's code was written with the assumption that only "root" would be able to invoke it, so if you already were "root" securing this didn't matter.

There are many, many more issues similar to these, too many for me to write about, and probably many that are way beyond my comprehension. I don't think it's wrong to say that Linux has not been very secure.

It is an accurate statement.

Linux is a monolithic UNIX-like OS, with all the implications of an accidental design that dates to the late 60s/early 70s.

For starters, it has huge (Linux has MLoCs) TCB. And it is very trusted (undeservedly so) code, as it runs with supervisor privileges.

One bug in these MLoCs is all it takes.

There are far better system architectures out there.

Yeah, I read that and thought "woah, shots fired". But I'm old enough to know the definition of "secure system" varies so widely from person to person, it's just pointless to bicker about it. Some people won't be happy until programs have to ask whether they can flip a bit in memory by presenting the user's blood for analysis.

Just because something is better than an alternative doesn’t make it “good,” it just makes it less bad.

AFAIK if you're an OS-head, this is meant in the sense that it was designed to be a *NIX, not fundamentally advance security or make better decisions. (but I'm curious to hear I'm wrong)

You probably need to interpret this as saying "the system is written in such a way that the application developer needs to take extra steps to secure their applications, compared to how it could've been written".

For example, privilege elevation in Linux is a very complex and complicated mechanism. The famed "sudo" command has a very long history of bugs. To the point that I remember RHEL peddling their own version ("ksudo" if memory serves... I cannot find any mentions of this, it was some 15 years ago). It's very hard to get things right. Especially, to prove that you've done things right, if you are after security.

The system interface is designed "for comfort" rather than "for security". Many things could've been a lot more secure, but very tedious on application programmer (imagine SeLinux, but in hyperactive mode... that's every sysadmin's nightmare).

In practice, with a lot of community effort, tools like "sudo" eventually reached a point where they are mostly reliable for what they are expected to do. So, to face practical threats, today, the system may be OK, but this isn't the testimony to its design, rather it is a consequence of how much effort was spent plugging the holes.

Reply on news.ycombinator.com