> > > > OpenBSD has only had something like two holes in over a decade > > which is nice for uptime. > > Let's not get carried away here. I was under the impression that > openbsd was one of the best things since sliced bread ... then I read > this: > http://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/
This article is wrong in many ways including saying it includes many of the features of grsecurity. They are actually quite different and saying OpenBSD implemented them after is simply untrue. You can lookup the author of grsecurity making this allegation on the OpenBSD lists if you wish. Saying systrace is recommended to protect from a succesful attack is also wrong. You have to such as with MACs know about things like syscalls and it is actually suggested you don't rely on it at all. Though systrace usage has been added to OpenSSH when run on OpenBSD recently. Not as a reliance but as an extra security measure against DOS attacks and chroot and dropping priviledges is used far more on OpenBD by default (possibly without users even knowing) than on Linux such as in the in base Apache, nginx, unbound, nsd, all of which are audited. Depending on MACS to protect from a succesful attack is bad security practice. The fact that admins time is better spent on preventing successful attacks in the first place and increased complexity of protections it brings is the reason OpenBSD advocates against MACs. Opening quote ________________________________________________________________________ "OpenBSD was not designed with security in mind and provides no real way to lock down and limit a system above standard UNIX permissions, which are insufficient." ________________________________________________________________________ It's kernel was and is designed with security in mind (as far as the generic hardware will allow). Linux is not. Only standard unix permissions is actually incorrect which he later leads onto. I shall let you decide what that means about this article. File immutabilitiy is a useful feature which Linux hasn't got in such a useful form and at the end of the day everything comes down to the kernel and it's memory protection. He doesn't seem to understand that programs can use protected memory and that memory and processes are better protected due to kernel design and randomness throughout. OpenBSD has securelevels and with the kernel being far more secure than Linux they are far more reliable than MACs. Without grsecurity. Linux doesn't even allow users to close off the gaping hole of rawio (linux) or video aperture (OpenBSD). Standard unix permissions are extremely powerful and I challenge you to come up with a situation where they are not especially when secondary groups are used. It is certainly clear however that many do not understand the power of unix permissions, especially Redhat. On top of this new technologies like PAM do not have the best security track record. It is worth noting that even if you have the time for SELinux it has had it's flaws (I actually prefer grsecurities RBAC). It is clear that the author even does not understand this. ________________________________________________________________________ "the user has complete ownership over their files and processes, and the ability to change permissions at their discretion. This leads to many security concerns, and is the reason most attacks can be successful at all" ________________________________________________________________________ That is not true but is likely over the files they create which can be cotrolled under a DAC system just like a MAC which also has to understand what the user is expected to be doing beforehand. ________________________________________________________________________ "the malicious process or user will inherit the access of the browser or process that was attacked. The prevalence of the DAC architecture throughout most operating systems is still the primary cause of many security issues today. With many server processes still running as a privileged user this is a large concern." ________________________________________________________________________ It's actually simpler better and more secure to drop priviledges and work on design. This can often be done by users and is often added to ports on OpenBSD. All then benefit and not just RBAC users. ________________________________________________________________________ "As an example of what is possible with extended access controls, it a web server process running as root could be set to only have append access(as opposed to general write access available in a DAC system) to specific files in a specific directory, and to only have read access to specific files in a specific directory. If some files need to execute, then that file itself (or the interpreter if a script) can be restricted in a similar way. This alone would prevent web site defacement and arbitrary code execution in a great many cases." ________________________________________________________________________ This guy obviously hasn't got a clue and no real experience of OpenBSD though it looks like he has tried to do his research. A web server does not run a root on OpenBSD and anyone who does so should not. I don't even allow my web server processes to write html files to their own web space. Obviously I have no need for CMS systems but even if I did why would I allow the www user to read system passwords as you can't chroot a root process (Note that a root process has more scope to attack the less secure Linux kernel under RBAC than a normal process in any case). Very few can afford the time to manage MACs in any case and they are only as secure as the kernel and protecting them and the kernel is only as secure as it's code and the policy allowances on the system. Often you here the fallacy that under SELinux root doesn't exist. Please realise this is rubbish, root is restricted by the kernel as it is on any system, just moreso. MACs won't help on a complex system and should be of no use on a simpler system such as a server. Perhaps there are corner cases of course but again time spent on good design would surely be better. _______________________________________________________________________ "This is simply a myth. While the frameworks themselves can be attacked and even possibly exploited, the increase in security far outweighs any risk" _______________________________________________________________________ So he admits they can add exploitability but doesn't understand the security which exists under DACs. I shall stop quoting now as this article is too wrong to keep going. Don't get me wrong if MACS existed on OpenBSD I would use them as I do systrace in some cases as extra layers but I wouldn't use them on root and only as a last bolt on. I wouldn't swap OpenBSD security features or DACs for them that's for sure. OpenBSD is not all about code correctness, though that and system design are the primary security tools of any system, it is about security as one of it's goals full stop. If you need an RBAC to protect your system you are doing something wrong and wasting your time that could be spent on real security. There is also another downside to RBACs. I have seen times where devs have said well if that's a problem or potential insecurity someone could use an RBAC to protect themselves anyway so I am going to ignore your concerns. Funny how there was not one mention of randomness that Linux still struggles with and yet OpenBSD can provide hundreds of megabytes per second of strong pseudorandomnes and no mention of OpenBSD randomising dns and TCP whilst Linux was vulnerable for years. Hardly balanced. _______________________________________________________________________ "This is simply a myth. While the frameworks themselves can be attacked and even possibly exploited, the increase in security far outweighs any risk" _______________________________________________________________________ -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130420232233.7ea32...@kc-sys.chadwicks.me.uk