Thank you so much for the explanation guys. It makes perfect sense now.
O.D. On 24. februar 2014 at 3:50 AM, "Nick Holland" wrote: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.