Re: what's your Debian uptime?
> >
> > 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)
_______________________________________________________________________
Reply to: