Re: More OpenBSD on Hacker News -- RBAC and jails anyone?
previously on this list Matthew Weigel contributed: 1. Why doesn't OpenBSD have something like RBAC? RBAC has a lot more knobs to tweak, so you can always go back after a security incident and say aha! I need to tweak *that* knob to prevent this next time! But it has a steep learning curve, and everything you don't know about how your RBAC is configured is as much a problem as everything you got wrong. Most people use RBAC on Linux by turning it off. Though of course you also have to set the time aside for dealing with problems from updates that constantly appear on the Gentoo Hardened list though it does provide an extra layer easily for simple systems, like systrace and chflags can to lesser degrees but conversely might reduce the effectiveness of chflags due to the higher likelihood of a kernel exploit especially on those complex systems where a great deal needs to be allowed by the RBAC/MAC. You certainly have to spend a long time configuring linux (which is thankfully very configure outable) and writing and auditing a lot of code to get RBAC anywhere near as uncircumventable as chflags and even DACs on an OpenBSD kernel. Grsecurity is a bolt on and so has many addon features like chroot escape prevention techniques but obviously struggles with upstream to get at the real important core of Linux and certainly cannot change the mindset of Linux which is features trump almost everything. Just look at systemd overruling the more security conscious and those that have atleast some understanding of the lower levels of the OS. Whilst I say security vs functionality is a myth due to time and the right care working around it, in general and by default it is often true. One of OpenBSDs primary goals is just that and the users learn from that. It's like trying to add armor to a land rover or designing it as an armoured vehicle in the first place. OpenBSD permissions are fairly simple, thoroughly considered, and set up with sane defaults. Most people continue to rely on just these basic controls, on OpenBSD *and* on systems with RBAC. What I find amusing is just how often it isn't a defence in depth approach because the power of DACs and priviledge seperation are hardly used or even barely understood by RBAC advocates. -- ___ '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) In Other Words - Don't design like polkit or systemd ___
Re: More OpenBSD on Hacker News -- RBAC and jails anyone?
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
Re: More OpenBSD on Hacker News -- RBAC and jails anyone?
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
Re: More OpenBSD on Hacker News -- RBAC and jails anyone?
On 02/23/2014 08:09 PM, openda...@hushmail.com wrote: 1. Why doesn't OpenBSD have something like RBAC? RBAC has a lot more knobs to tweak, so you can always go back after a security incident and say aha! I need to tweak *that* knob to prevent this next time! But it has a steep learning curve, and everything you don't know about how your RBAC is configured is as much a problem as everything you got wrong. Most people use RBAC on Linux by turning it off. OpenBSD permissions are fairly simple, thoroughly considered, and set up with sane defaults. Most people continue to rely on just these basic controls, on OpenBSD *and* on systems with RBAC. 2. Is chroot really inferior to FreeBSD jails? As best as I can tell, jail basically accomplishes three things: it severely restricts even the root user inside the jail, it lets you restrict some bad things from occurring inside a jail, and it hides processes outside the jail. The first part is interesting from a virtual root access standpoint, but adds a lot of code and complexity for that one use case. The second part (e.g., not allowing LKM inside the jail) is really only a good idea if you thought letting people do those things outside the jail is still good... on OpenBSD you can control most of those things globally. The last bit seems pretty uninteresting, unless (again) you are trying for virtual root access. -- Matthew Weigel hacker unique idempot . ent
