On Sunday 01 December 2013 09:41:42 Nico Kadel-Garcia wrote: > On Sat, Nov 30, 2013 at 3:31 AM, ToddAndMargo <toddandma...@zoho.com> wrote: > > Hi David, > > > > Loved the article. I understood all about the cartoons and > > > > the dogs and cats. Perfectly done. Unfortunately, when the > > real world kicked in: zoom, right over my head. > > > > Who sets up these labels and how is that done? Some GUI > > > > for this? > > In theory, people like David, when creating RPM packages, incorporate > some guidelines. And in testing, one can set SELINUX to "permissive", > and record what violations are being reported. With that in hand, and > some system knowledge, you can tune the SELinux settings, update the > package installers, and go another round. > > In practice? Few developers are willing to help write good packages, > and many completely ignore the File System Hierarchy, so they wind up > putting stuff in all *sorts* of places. And it winds up the RPM > authors' problem to straighten out any SELinux conflicts. Our friends > upstream at Fedora and Red Hat are pretty good about it. But when > developing home or buisiness layouts with personnel who've not dealt > with it, it's usually easier to just turn SELinux off or set > permissive, and try to clean up if and when you have cycles.
Authors with good ideas and no understanding of the system they are writing for are the bane of Fedora packagers. (In Fedora there are all these rules and things...) That said, audit2allow goes a long way to letting a user painlessly generate a custom policy from the audit logs generated in permissive mode. Understanding how to do this requires a bit of reading, though -- I'm not sure if that functionality has all made it to the GUI. Speaking of which, I'm not sure that the GUI bits are in SL, but I know they are in Fedora (and probably EPEL?). On really huge software systems audit2allow is insufficient and a unique domain/policy needs to be deliberately created. In large systems the occurrence of critical activities might be so rare (once a month or perhaps just randomly based on an event/condition) that not everything that needs to be allowed can be captured in the audit logs in a reasonable amount of time. Complex, long-running server-side stuff like Apache (or even desktop packages like certain browsers that think they are window managers themselves) can fall into this category, and in those cases its a big deal to have packagers and developers talking. In most cases, though, audit2allow is entierly sufficient and easy to use once you understand it. That is assuming, of course, that you care about locking things down on your system -- there is strong historical evidence to support the view that most consumers couldn't care less about security, privacy or their own property rights so long as the digital haze they experience is sufficiently distracting. Hence the developers' conundrum: users prefer insecure systems with lock icons on everything to systems that are even partially secure.