On Fri, Jan 22, 2010 at 07:22:58AM -0600, Marco Peereboom wrote: > It doesn't and I'll argue all day that it won't help you a bit.
I couldn't agree more. > BTW, microsoft implemented every single ACL type mechanism the NSA ever > made public. Tell me again how well it worked for them. More importantly, how well has it worked for end users doing general computing tasks? Glancing through the author's other posts, I don't get the feeling that this person is in an environment that needs the level of security that the NSA does or has ever been in one. Most of the posts revolve around removing malware from Windows XP or which virus scanner is the best... <sarcasm>I'm not sure why ACLs have not helped this person in those situations.</sarcasm> Nowhere in the article is proof provided that OpenBSD is insecure. There are comparisons made. "OS A has 'this', OS B has 'that'. OpenBSD does not. So, OpenBSD by comparison is less secure, therefore insecure". It's non-sense. There isn't even proof that feature "this" or feature "that" have provided stronger security. Those features are not enabled by default and are often tedious to get working correctly. Basically, OS A does not benefit from "this" out of the box and OS B does not benefit from "that" out of the box. They are strawman arguments with no actual facts. The benefits of OpenBSD are not even covered. The author claims OpenBSD makes no effort to contain unauthorized remote access, yet many of the default daemons attempt to contain security breaches through reduced privileges and chroot. Basically, the same effect the author claims a MAC system would give you (if that system were infallible and effective, as the author blindly believes). It's built into the daemon, by default. How did the author miss this? I also do not understand why strlcpy and strlcat are causing the author so much grief. This person didn't seem to know they existed before writing the article. I work in an ISP environment and it has caused zero issues to both myself and our users. Of course, the author does not provide any real world examples of issues or exactly what code has been broken by use of strlcpy or strlcat. The author also missed how OpenBSD's current methods match it's development model very well. The OpenBSD developers are in control of all the code. There aren't 3rd party patches being introduced daily that change thousands of lines of code with unknown consequences or unintended interactions with the existing code base. Correcting the code works very well for OpenBSD. The only facts I actually got from the article are (1) OpenBSD does not have some type of MAC, which I already know, and have no problem with, and (2) the author does not like OpenBSD and wants you not to like it, too.
