[Novalug] October Talk -- SELinux for your (grand)parents
greg at pryzby.org
Wed Sep 29 06:57:53 EDT 2010
As usually, we disagree ;)
I will put your non-SELinux box vs a SELinux. Let's put the root
password out there and default install (one w/ SELinux enabled and 1
disabled) and see what happens
There WAS a time that SELinux was hard, heavy, etc. That is no longer the case.
Just like I stopped using RPM-based distros in 1999/2000 (and gnome) I
decided to see if things had changed and sure enough, yum and gnome
have matured to give me the experience I want.
Well, I use gnome-shell, but you get the idea...
On Wed, Sep 29, 2010 at 12:41 AM, James Ewing Cottrell 3rd
<JECottrell3 at comcast.net> wrote:
> I started a point by point reply, but it got too radical, too involved, so I
> will just mention the main points.
> I object to the Complexity and Ugliness of SELinux. I am satisfied with the
> existing UID/GID/permission scheme.
> I feel that lately, Too Much as been made of Security, that the Tail is
> Wagging the Dog. I'd rather spend more time Actually DOING something useful
> instead of worrying about endless minutiae.
> Give me a Bass and Treble control. I don't want a Graphic Equalizer.
> Everything should be made As Simple As Possible. Especially Security.
> If you are worried about your IM Client or Browser getting into your
> Financial Data, then maybe you are already Too Complex.
> Stop trying to recreate Multics.
> On 9/28/2010 11:09 PM, David A. Cafaro wrote:
> Figured I'd take a swing at answering some questions as well. I'm by no
> means an expert but I have been working with SELinux for a few years.
> Currently run it enforcing on my Netbook and Desktop.
> On 09/28/2010 07:19 PM, James Ewing Cottrell 3rd wrote:
> On 9/28/2010 11:15 AM, Paul W. Frields wrote:
> On Mon, Sep 27, 2010 at 10:59:49AM -0500, Beartooth wrote:
> (OK, most
> people wouldn't do that, but you get the picture.) Similarly, when
> someone hits your web server, or your music share, etc., you don't
> want them to be able to exploit a security bug and get at documents
> they have no business redaing. When you load a page in your browser
> you don't want the browser code to be able to fiddle with stuff
> outside its purview.
> And how would a chroot for your browser NOT fix that? We use chroots for
> Servers, why not Clients too?
> If you chroot your browser/clients, how many libraries do you then have
> to replicate in each chroot environment to get them to work? How many
> applications? Chroot works great for servers when you have one primary
> application to worry about, but if you start getting into multiple
> applications and multiple chroots with multiple copies of all the same
> files, your long term management starts looking like a nightmare.
> Fixing a centralized access policy in a central location which can be
> updated reasonably easily through the life of the system and allow of
> easy application updates seems to be a better way forward.
> Or simply modify the kernel to let any process do a setuid(nobody).
> Or better yet, treat Users like Networks. Each user gets a subuser mask,
> and can setuid any to any user within their
> user network (as well as extend the subusermask). Log me in with a UID
> of 654.0, and allow me to setuid to 654.1 thru 654.255. Works for FM and
> TV stations.
> User.0 can access anything within user.x, but not vice versa, nor can
> subusers setuid back. User ownership equivalance is tested for by anding
> the subusermask with the object owner and comparing it to the existing UID
> Interesting idea, but you start heading down this route and your likely
> just going to be designing yet another security system that will show
> the need for more complexity as it's thought out. Might be a good idea,
> but why not take advantage of something available now that a lot of
> people have poured a lot of resources and analysis into already?
> When userspace is exhausted, we can create Userv6 :)
> Oh, and By The Way, while SELinux CAN be user to keep your clients out
> of each other's hair, so far it's only used for Servers, not Clients? Or
> are you saying that's changing?
> I use it on clients and it works great. Still needs more hardening, but
> it's getting better, and it doesn't break anything for me, which is good
> on the client side.
> But seriously....look how easy it is to come up with Rational, even
> Beautiful Alternatives without pissing all over the filesystem.
> It actually become harder than it might seem as you start to look
> further into what SELinux can do. One thing you have to remember is
> that being able to "piss all over the filesystem" gives you a great deal
> of control. SELinux manages network/sockets/pipes just as well as
> regular file systems, it's Linux, everything is a file. So you can
> specify similar read only, write only, stat only, etc controls for just
> about anything you can think of.
> Beyond this you've got MLS capabilities which though not really
> implemented much yet, can provide levels of separation on systems that
> chroot and other security mechanisms won't.
> I think SELinux biggest hurdle is that by default it denies everything,
> you then have to build up the policy to allow things to work. When it
> was first released the policy was pretty limited and the tools to work
> with it were a little weak. It was new, it stopped you from doing all
> the things you were used to doing (regardless of whether you should or
> should not have been doing it) and people hence said it was too much of
> a pain and should be disabled by default.
> Thankfully some groups decided to keep pushing it forward and it's come
> a long way. It's not a substitution for other security practices: code
> review, proper coding technique, proper system management, etc. But it
> can help to protect from mistakes and in some ways enforce better system
> design and programming.
> I have several systems in the house that are used by my family
> exclusively and they are all SELinux enabled. I know from personal
> experience that it's rare to have any problems with SELinux, and on
> those rare occasions I find a relabeling fixes everything.
> This is a truly worthwhile technology, and personally I'd be leery of
> advice from someone who tells me to simply disable it for expediency's
> I would also be leery of random people on the Internet telling me I was
> Dangerously At Risk without the latest and greatest Security Technology.
> P.S. You didn't answer My Big Question either, altho in fairness, it
> wasn't directed to you specifically. Do all vendors use The Same Labels
> on The Same Files? I want my Filesystems to be used by several different
> OS, possibly at the same time.
> I'm not 100% on this, but at one time most policies were based of a
> central Strict and Targeted policy provided by NSA and later the
> Reference policy maintained by Tresys. I'm not sure if that is still
> what distributions do. Most files should be fine as for as labeling,
> and I don't believe anything is stopping you from sharing a working
> policy for a file system between multiple distros if they are all
> accessing/using the same filesystem and supported the same policy
> version. Your biggest problem will not be the labeling but the
> placement of files and the differences in sysinits and /etc filesystems.
> Userspace files should be a relative breeze.
> Unfortunately Windows doesn't support SELinux (or by default ext3/4
> file-systems) so the file labels won't work. And OpenBSD will likely
> laugh at you if you ask, they have their own way of doing things. At
> one point some porting of SELinux to MacOS was going on, but not sure if
> the labeling would match, or if that's still active. Android doesn't do
> it either, but I'm going to look into that later.
> Novalug mailing list
> Novalug at calypso.tux.org
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.856 / Virus Database: 271.1.1/3165 - Release Date: 09/28/10
> Novalug mailing list
> Novalug at calypso.tux.org
greg pryzby greg at pryzby dot org
More information about the Novalug