| |||||||||||||
A kernel.org status updateA kernel.org status updatePosted Sep 26, 2011 13:23 UTC (Mon) by malor (subscriber, #2973)Parent article: A kernel.org status update Or, hey, they could write the kernel with enough focus on security so that you could reasonably share a machine among multiple, potentially hostile users. It's pretty goddamn sad when even kernel.org doesn't trust Linux enough to give out shell accounts.
(Log in to post comments)
Defence in depth Posted Sep 26, 2011 14:05 UTC (Mon) by alex (subscriber, #1355) [Link]
There is no such thing as a totally secure networked multi-user kernel. It would be foolish to rely on only one layer being secure and given that most of the git users don't need shell access to push to their repos this seems a sensible measure.
Defence in depth Posted Sep 26, 2011 14:12 UTC (Mon) by malor (subscriber, #2973) [Link] There's no such thing as a totally secure networked anything.The simple fact is that the kernel.org people don't think that the Linux kernel is secure enough to allow shell access. This is a powerful vote of no confidence, and should be a source of real shame for the kernel hackers. Your continued scorn of security will continue to bite you in the ass.
Defense in depth Posted Sep 26, 2011 14:24 UTC (Mon) by smurf (subscriber, #17840) [Link]
Face it. No system out there is 100% secure. There's always be another bug to exploit to be found, the kernel is too complex for anything else.
Therefore, a good risk mitigation strategy is to reduce the attack surface. A bug is found that's only exploitable with shell code? Fine, if the machine doesn't give you a shell, you're safe. (Unless you find a bug in another program you can access which has a bug that gives you a shell.)
This is not Linux specific. Every other nontrivial OS out there exposes you to the same set of risks, more or less.
A real vote of no confidence would be if they chose to run kernel.org on *BSD
Defense in depth Posted Sep 27, 2011 16:14 UTC (Tue) by nix (subscriber, #2304) [Link]
A real vote of no confidence would be if they chose to run kernel.org on Windows 7.
Defense in depth Posted Sep 29, 2011 21:45 UTC (Thu) by cdmiller (subscriber, #2813) [Link]
Perhaps openbsd...
Defence in depth Posted Sep 26, 2011 14:30 UTC (Mon) by cesarb (subscriber, #6266) [Link]
It is not just the kernel.
There are several classes of user-space exploits (/tmp races, setuid binaries, and so on) which are exploitable only if you have a shell or equivalent access.
Even if the kernel were 100% secure, you would still be increasing the attack surface by giving shell access.
Defence in depth Posted Sep 26, 2011 14:56 UTC (Mon) by mpr22 (subscriber, #60784) [Link] A well-secured system doesn't offer unnecessary facilities to its special-purpose users. Anyone who doesn't need shell access on kernel.org's servers shouldn't have shell access on kernel.org's servers.
Defence in depth Posted Sep 26, 2011 19:53 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
There ARE totally secure networked multi-user kernels. Here it is: http://ertos.nicta.com.au/research/l4.verified/
Formally verified kernels which are immune to stack overflow and other low-level hacks are a-plenty. Even hardware IOMMU is common already.
So a secure OS is possible and probably would be implemented sooner or later.
Defence in depth Posted Sep 26, 2011 20:23 UTC (Mon) by nevets (subscriber, #11875) [Link] There ARE totally secure networked multi-user kernels. Here it is: http://ertos.nicta.com.au/research/l4.verified/From their own FAQ. Is seL4 proven secure? No, it is not. The proof states and shows functional correctness, not security. Functional correctness implies the absence of many security common problems, provided the proof assumptions hold (see also the longer version), but it does not mean that the kernel or system as a whole is "secure". Such a statement would first require a precise mathematical definition of what secure means. We are working on proving precisely defined, high-level security properties of seL4 in the future. These proofs will provide stronger assurance than what is possible of current systems, but they will still be up to assumptions and classes of attack vectors. [bold added by me] So a secure OS is still not possible. At least no one has done so yet.
Defence in depth Posted Sep 26, 2011 20:51 UTC (Mon) by smurf (subscriber, #17840) [Link] Also, from the same FAQ:Microkernels typically do not provide device drivers, file systems or network stacks. A secure kernel without storage or networking is somewhat under-featureful to run on machines like kernel.org, I'd say. Have fun formally specifying the operation of your typical high-end network adapter or SATA controller. You'll need it; see you in a few years. ;-) There's also no formal proof for multi-core systems, arguably also a necessity these days.
Defence in depth Posted Sep 26, 2011 21:27 UTC (Mon) by dgm (subscriber, #49227) [Link]
> So a secure OS is still not possible. At least no one has done so yet.
I would be more correct to say that, even if someone did a completely "secure" OS, we cannot prove it as we don't know precisely what "secure" means. But this doesn't rule out the existence of a it, just that we cannot be sure.
Defence in depth Posted Sep 26, 2011 22:15 UTC (Mon) by cmccabe (guest, #60281) [Link]
Well, there is Quebes, which is a little less pie-in-the-sky.
disclaimer: I haven't actually gotten around to trying this "distro."
Probably the most interesting thing they've done so far is sandbox networking code using IOMMU/VT-d.
Defence in depth Posted Sep 27, 2011 16:18 UTC (Tue) by nix (subscriber, #2304) [Link] Probably the most interesting thing they've done so far is sandbox networking code using IOMMU/VT-d.That assumes you have a machine on which this works, and is secure. Even the first is hard (my machines are top-end systems less than two years old and VT-d works on neither of them: on one it just fails to do anything useful and on the other it locks up the system hard on boot unless VT-d is turned off): the second is probably impossible given that huge holes requiring firmware-level changes were still being found in VT-d as recently as a few months ago. Are there any left? Do you feel lucky?
Defence in depth Posted Sep 27, 2011 20:59 UTC (Tue) by cmccabe (guest, #60281) [Link]
Hmm, I didn't realize this feature was still so buggy. Still, in a few years, it will probably be considered as standard as the VT-x extensions.
IOMMUs are an interesting feature. I think if they had existed back in the 80s or 90s, operating systems might have evolved quite differently. Putting device drivers in userspace doesn't seem quite so absurd if they can access I/O ports safely. Of course, there are a lot of other things that would need to happen to make that a realistic choice, but it at least opens the door.
Defence in depth Posted Sep 27, 2011 23:06 UTC (Tue) by mpr22 (subscriber, #60784) [Link] Didn't Sun boxes have IOMMUs in the 90s? (OK, not exactly commodity hardware...)
Defence in depth Posted Sep 27, 2011 3:37 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, it depends on a definition of 'secure'. At least, SeL4 is formally correct and verified which automatically kills a lot of possible attack vectors.
Capability-based security properties are easily proven, but not very interesting.
Defence in depth Posted Sep 29, 2011 12:49 UTC (Thu) by trasz (guest, #45786) [Link]
Of course it is. STOP (XTS-400), for example.
A kernel.org status update Posted Sep 26, 2011 22:32 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link] It's not just the kernel, though; you can be compromised through userspace or social engineering. In this case, for example, there's no indication that the initial compromise had anything to do with the kernel being insecure. Running a system securely involves more than just software; it requires good procedures as well. Limiting the number of people who have shell access to key servers is one part of those good procedures.
A kernel.org status update Posted Sep 27, 2011 7:29 UTC (Tue) by dsommers (subscriber, #55274) [Link]
Even the strongest, most secure piece of software might have vulnerabilities. There is no such thing as a completely secure software, nor hardware.
Building a secure system is like building a secure house. You can remove all doors and windows, but you can't get in and out from it. But you might have ventilation holes to be able breathe inside, and that can be yet another vulnerability (what if someone brings a water hose...?) You can build it on the top of a mountain - even without ventilation, without roads, or wires to this house. But it'll be pretty useless, as you can't do anything else than to observe how it looks from the outside (inside you wouldn't really survive). And still somebody can decide to send a rocket through your walls.
So as long as you want to have a computer on the Internet, you need to connect it to a network (a road to the house). And you need to enable some services (doors and windows) to be able to do something useful with it. Then security depends on what kind of services you open up and what kind of security layers ("guards" protecting the "house") you implement - which can be firewalling with or without deep packet inspection, SELinux, AppArmor, tcpwrapper, authentication mechanisms, etc, etc.
The only thing in which can make things more secure is layers of security mechanisms. If something nasty passes one layer it will hopefully be caught in the next layer. But in the end, it's really difficult to only catch the nasty stuff and only let through the good stuff.
A kernel.org status update Posted Sep 27, 2011 16:33 UTC (Tue) by nix (subscriber, #2304) [Link]
Extending the same metaphor, DigiNotar had a fortress in a distant barren land, with foot-thick stone walls... and a four-lane highway extending up to the entrance, and a one-cylinder lock on a door made of cardboard.
|
|||||||||||||