5 ms·
I would hesitate to call something Secure unless some major pen test effort were engaged to try to break it. This is a corollary to "If it isn't tested it is b
by wglb 9y ago
I would hesitate to call something Secure unless some major pen test effort were engaged to try to break it.
This is a corollary to "If it isn't tested it is broken". (Another corollary is "Even if it is tested, it may still be broken.") This is more so with security.
Just looking at some of the assumptions, e.g., that the lack of a shell significantly increases the difficulty of an attack, leaves me with doubts about the claims.
- dvfjsdhgfv 9y agoMy thoughts exactly. If they wrote "more secure", this would make more sense. In the current form it's just boasting.
- perbu 9y agoHi author here. I agree wholeheartedly. I wasn't thinking in absolutes, but I absolutely can understand how it could read that way. I could have titled the post "Unikernels are resonably secure", but then nobody would have read it. I was doubtful about mentioning the lack of shell. Technically it doesn't really do much in terms of security, but it does make a compromise harder. And currently, where we stand, a lot of the security comes from things being really, really hard to compromise. Guessing adresses, not having a shell, potentially no filesystem, etc.
- wglb 9y agoWith "Unikernels are reasonably secure", but then nobody would have read it., you might also take into account whether the audience, having read it, are happy that they did. The title sounded pretty absolute. So you do have a noble goal. When I am asked to assess software, to gain a first order approximation, I often look at the culture of the organization that produced it. On the high end, that often translates to some sort of formal process involving un-fun letters like 'ISO' and 'SOC'. For smaller organizations, or OSS software, I try to get a feel for how the developers seem to be thinking about security. Some of the cultural things I see in your writeup are encouraging--Smaller Codebase, Removing hardware emulation, Cutting off access to ring 0--all bode well for how you are thinking about producing secure software. But there are some things that are missing from your description. What is your development process? In particular how and when do you attack your assumptions about how the code actually works? What flaws have you found in your testing? Zero findings could mean 1) it wasn't tested 2) it wasn't tested very hard 3) the testers were not very good at security testing. And as OpenBSD's history has illustrated, some things are totally secure until they aren't.
- dvfjsdhgfv 9y agoTo be fair, I enjoyed reading the article. My conclusion though is that unikernels (an interesting concept in itself) offer only a part of the functionality of a standard OS. As such, it might actually be easier to limit the functionality of a general OS in such a way that it does only what needs to be done and nothing more - and there already some relatively mature solutions for that.
- cwp 9y agoYes, exactly. The article would be much stronger if it also covered ways in which unikernels either don't improve security, or are actually more vulnerable.
- xroche 9y ago> I would hesitate to call something Secure unless some major pen test effort were engaged to try to break it. Precisely. On another domain: "My crypto algorithm has never been broken, it is secure". No it is not, it's just too irrelevant for anyone to be interested in auditing it.