From mboxrd@z Thu Jan 1 00:00:00 1970 From: dac.override@gmail.com (Dominick Grift) Date: Mon, 29 Aug 2016 10:20:48 +0200 Subject: [refpolicy] [PATCH v4] Update for the gnome policy and file contexts In-Reply-To: <2fdc38c8-f5af-b255-078e-fc06fb67b702@gmail.com> References: <1471099545.21480.27.camel@trentalancia.net> <1471296811.28802.0.camel@trentalancia.net> <1471704772.17584.9.camel@trentalancia.net> <1471894798.19333.1.camel@trentalancia.net> <1471956294.17467.4.camel@trentalancia.net> <1472075733.19800.4.camel@trentalancia.net> <1472317696.28955.1.camel@trentalancia.net> <1472318213.31962.2.camel@trentalancia.net> <1472330498.25935.7.camel@trentalancia.net> <1472334513.25935.16.camel@trentalancia.net> <6b1697f1-2aaf-3727-5b69-8794a0f85530@gmail.com> <7EAFAD82-CDDA-47E3-950E-4D5610686C6C@trentalancia.net> <2fdc38c8-f5af-b255-078e-fc06fb67b702@gmail.com> Message-ID: <95f574ae-74ec-b86c-dc4a-7d36b4b7ff00@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/28/2016 09:12 PM, Dominick Grift wrote: > On 08/28/2016 08:40 PM, Chris PeBenito wrote: >> On 08/28/16 11:37, Guido Trentalancia via refpolicy wrote: >>> Things are very far from working naturally as they are. >>> >>> On the other hand, the patches are surely far from being complete or >>> stable yet, but at least every version allows to start the Gnome desktop. >>> >>> Now I met this major problem, it looks by all means a limitation of >>> the existing framework, but I am sure that it will be sorted out... >>> >>> I am also waiting to hear from Christopher about this. >> >> The way I see it is that general purpose desktops are incredibly >> complicated and are not designed with security in mind. I wonder if the >> policy complexity needed to confine it all actually buys a proportional >> amount of security gains. I'm not saying it shouldn't be done, but I am >> skeptical that it is worth it. >> > > It is expensive. I agree, but i would not go so far as to say that > confining the desktop does not buy a proportional amount of security gains. > > It is telling though that you're not the only authority saying that > using selinux to confine the desktop is not practical (Walsh shares your > opinion). > > Anyhow DSSP fills a gap here. So if you value integrity on the desktop > DSSP is be happy to take contributions :) > SELinux is a flexible MAC, and it is designed to be a framework to address the widest range of access control challenges. It is THE tool for this job. Were talking Access Control, this is not just about containing flawed or malicious code. We use access control to govern who can do what as well. I will be the first to agree that desktops aren't designed with security in mind. That is one of the reasons we need to contain it. Some of the code in there looks downright disturbing. My shell is "fragile" I will be the first to admit. But at least I have an excuse (dropped out of kindergarten), plus i know its "fragile" and so i contain my own code. SELinux is not "practical" at all (until its is the only tool left capable enough to do the job). Desktop or not. Ask 10 random people, and I am willing to bet that at least 8 of them agree. Heck security is not practical! Our identities. passwords and other authentication credentials are pretty much all we have on this network called Internet. We should do all we can to protect it. On a desktop, the desktop is generally the most vulnerable. Yes we need to contain the system side as well, but A desktop generally has much less of that compared to a server. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160829/a9e0bfcb/attachment.bin