[Novalug] October Talk -- SELinux for your (grand)parents

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.
>
> JIM
>
> 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
> sake.
>
> 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.
>
> JIM
>
> 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.
>
> Cheers,
> David
>
> _______________________________________________
> Novalug mailing list
> Novalug at calypso.tux.org
> http://calypso.tux.org/mailman/listinfo/novalug
>
> 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
> 13:41:00
>
>
>
> _______________________________________________
> Novalug mailing list
> Novalug at calypso.tux.org
> http://calypso.tux.org/mailman/listinfo/novalug
>
>

-- 
greg pryzby                              greg at pryzby dot org
http://www.linkedin.com/in/gpryzby

WEB:  http://www.RestonArtisTree.com/
TWTR: gpryzby