On 02/23/14 21:09, openda...@hushmail.com wrote:
> Hello,
>
> Got some more layman's questions here after reading
> [url snipped]
>
>> > OpenBSD for security
>>
>> I dunno, I hear this a lot. Sure OpenBSD has created and implemented
>> some (often very bleeding edge) hardening features, but nothing that
>> hasn't seen the light of day in something like GRSecuriy.
>>
>> But the lack of other security layers and constructs seem puzzling
>> to me. No RBAC-based system like selinux? No attempt to secure the
>> supply chain until very recently with package signing? Chroot
>> functionality inferior to something like FreeBSD's jails?
>>
>> Not to mention that many services you would deploy an OpenBSD server
>> for are provided by ports and not the base system, forgoing the
>> strict auditing that OpenBSD provides.
>>
>> [... snip ...]
>>
>
> 1. Why doesn't OpenBSD have something like RBAC?
Security means a lot of different things to different people. If you
are running an old-style multi-user system (i.e., lots of people have
terminals on their desk, all logging into the Big Computer In Another
Room), where most of the users are of very limited access rights, and
you need to carefully manage what they are getting to, yes RBAC ("Role
Based Access Control) is a great help. And maybe OpenBSD isn't your
first choice.
However, OpenBSD systems are often deployed for web services or network
services (or single-user systems like desktops). The only people with
access to the OpenBSD command prompt are usually either moderately
trusted or have administrative rights through sudo anyway. For this,
RBAC is just extra baggage, something that's more likely to be exploited
than to be useful.
OpenBSD's security model is more about -- as I phrase it -- keeping the
bastards out, not controlling them (or hoping to control them) after
they are in. Making life difficult for attackers once they get into
your system is usually not going to be overly productive, and usually
makes administration of the system much more difficult, which often
creates NEW security problems of their own. While people like to talk
about "Defense in depth" -- and it is not a bad idea -- your best goal
is to keep the bastards on the outside of your systems, as once they are
in, they can utilize anything you don't have perfectly bolted down to
accomplish their goals (and yes, that statement puts me opposite a lot
of people making a lot of money chasing down bad guys AFTER they
inflitrate systems).
In the Real World: First thing most people do on an SElinux system is
disable SELinux. At that point, all the RBAC "features" are now just
pure glossy advertising -- worthless. For fear of breaking things, the
Linux people have chosen to put a big on-off switch on SELinux...and so
given a choice between fixing applications and turning off the
switch...people just turn off the switch. ANY claimed benefits of
SELinux are ONLY there if it is enabled and used properly.
> 2. Is chroot really inferior to FreeBSD jails?
define "inferior".
Properly implemented, a chroot is pretty close to doing exactly what it
claims to do. Combined with good coding, like privilge separation, it
can make apps pretty darned secure. But, it is hard to retrofit onto
poorly designed apps.
Stuffing a poorly designed app into a FreeBSD jail may be better than
running it as it was intended, but history has shown that poorly
designed applications are usually security problems, and a jail may not
prevent that at all. At best, a jail will prevent Application A from
messing with Application B or the underlying OS, but it won't help one
bit in keeping Application A from being exploited, and if the exploit is
"useful", mission accomplished.
Jails look like a maintenance nightmare... created by building from
source? oh my... Haven't done this myself, but it doesn't look like fun
on a large number of machines. Or a machine I have 30 minutes to do an
upgrade on. or 90% of the machines here in my house.
As for GRSecurity...well, looking at their website, it is still a bunch
of patches for Linux to be applied by the user; it still doesn't seem to
be incorporated into any mainline Linux distros. I suspect this says
far more about the Linux mindset than the merits of GRSecurity (even if
the GRSecurity implementation sucked horribly...FIX IT and then
incorporate it! Sheesh!)
What's different about OpenBSD is that the features like stack smash
protection and W^X are in the base system, on all possible platforms
(and a few that didn't seem possible at first!), always on, and there's
no easy "off-switch", so crapplications HAVE to be improved in order to
work. I can't prove this (and I doubt anyone could), but I suspect that
OpenBSD has resulted in more improvements to programs commonly used on
Linux than GRSecurity has.
A lot of people like to say "OpenBSD doesn't matter because few uses
it", if that's true, then I think it is safe to say that "GRSecurity
matters even less". I don't think either statement is fair, but I would
like to see the code protection tools of GRSecurity in Redhat and Debian
and other major Linux distros and without an SELinux-style off-switch.
See...the problem is, you can't implement code quality features if your
code has poor quality. OpenBSD didn't embrace "tricks" like W^X or
stack protection until AFTER they were pretty confident about the code
in the base system. Auditing existing code is completely thankless
work. You spend a lot of time, make a bunch of changes to the code base
... and no one notices a thing. You get far more praise making features
like SELinux or GRSecurity that are not actually USED, and CAN'T be used
until someone commits to making the code to be run suck a lot less.
REAL security is not a list of features, even if used.
The OS is just the tip of the security iceberg...or maybe more
accurately, the base of it. You don't typically run an OS to run an OS.
You run the OS to run applications, and if those applications are
poorly written or poorly designed, there are limits to how much (if at
all) the OS can help. The best OpenBSD can do is give you a good
starting foundation.
Nick.
