-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/06/2010 05:57 PM, Daniel J Walsh wrote: > On 12/06/2010 10:18 AM, Dominick Grift wrote: >> On 12/06/2010 03:43 PM, Daniel J Walsh wrote: >>> On 12/05/2010 04:44 PM, Dominick Grift wrote: >>>> On 12/05/2010 10:29 PM, Mr Dash Four wrote: > >>>>>> I've been through this duplicate declaration/out of scope issues many >>>>>> times. It is one of the reason that i maintain my own policy instead of >>>>>> using fedoras' policy. >>>>>> >>>>> I do something similar - for different machines (which have different >>>>> requirements) I have prepared separate patches based on the version of >>>>> the fedora policy used and I just apply them (looking for >>>>> failures/hunks) when a new version of the policy is released. > >>>>> One of the things which annoys me no end in the fedora policy is using >>>>> the scatter-gun approach and granting access to the 'generic' >>>>> net/node/interface to a host of modules as well as granting access to >>>>> all 'client' packets. That is fundamentally wrong imo! > >>>> That is actually not a Fedora specific issue. Upstream refpolicy has the >>>> same. It is done to preserve compatibility. People that use the >>>> networking controls are expected to be able to customize the policy i >>>> believe. > >>>> I think that Fedora and refpolicy are discussing to make this work in >>>> other ways. I personally have no problem with it since i do not use the >>>> network controls any ways. > >>>> My issue with Fedora policy is: > >>>> stuffing stuff into base. >>>> - Means module cannot be disabled/replaced. Means youll more often get >>>> into duplicate declaration / out of scope issues. > >>>> fedora (and refpolicies for that matter) vision for the user space. >>>> - they both have different visions that cannot co-exist in one policy. >>>> (fedora's unconfineduser module is one issue) > >>>> Both Fedora and refpolicy do not have the desktop layer confined. which >>>> means users interact directly with the system layer basically bypassing >>>> the desktop layer. (which means the userdomains need much more >>>> privileges than they would if the desktop layer was confined) > >>>> Fedora easily permits access to all user home content which is not good >>>> for confinement of the user space. ( i like to keep things least privilege) > >>>> Fedora and refpolicy both have many unconfined domains. >>>> - Means that it you want to make an unconfined domain, confined. you >>>> will most likely first have to fix a bunch of bugs (because fedora >>>> developed the policy as being unconfined) In my view all domains should >>>> atleast in rawhide be confined. When it goes stable they can make them >>>> unconfined but it should as much as possible work confined as well. > >>>> Not that when i remove the unconfined_domain() interface that i have to >>>> spend a week to make things work. > >>>> But easier said then done. Fedora in the meanwhile also has to deliver a >>>> workable product for the general audience. > >>>> I dont have that problem with my personal branch, and thats why i just >>>> maintain my own stuff. No one to tell me what to do... no pressure.. >>>> just fun and security. > >>>>>> Sorry, i have not tested it. >>>>>> Yet, i am pretty sure it would work in my personal policy. >>>>>> >>>>> I'll do that tomorrow when I have the chance! > > > > >>> Dominick did you check these changes into the Rawhide branch? > >> No, some issues are easier to solve than others. Some issues would have >> a pretty big impact on policy in the short term. > >> issues should in my view be discussed in depth first with all parties >> involved, and should find common ground first (fedora and refpolicy) >> because implementing this would require a lot of work and changes. I >> also do not have all answers to all issues yet and i would want input >> from other experienced parties first. > >> My view is that Fedora/refpolicy should foster modifications by >> end-users. That means that we should at least make it possible to >> tighten policy more. > >> So i am *not* saying: > >> - no unconfined_domains(). >> i am just saying not by default. Atleast not in the development branch >> i guess we could make them conditional and just toggle them off in >> rawhide and toggle them on when it gets branched. > >> - no access to all user content. >> i am just saying preferably not by default (atleast make it >> conditional). and that we should aim to make it also work without in >> some scenarios. This is related to bypassing the desktop layer. so for >> example if the "use desktop layer" conditional is true then dont allow >> access to all user content (where possible) else be a bit more permissive. > >> - no bypassing of desktop layer. >> i am just saying lets try not bypassing it possible and maybe even >> default. Maybe make the bypassing of the desktop layer optional/conditional. > >> Like i said its easier said than done. I have some good ideas that work >> for me but my policy does not have as many requirements as fedoras >> policy has. > >> If i thought i could deal with all these issues by my self, then i would >> have made the changes to the fedora branch myself. I think instead we >> all need to understand and share the same vision and goals so that we >> can combine our efforts. > >> Getting modules in fedora out of base will mean in my view that large >> chunks of policy will no longer work in the current shape and will >> likely need to be reimplemented. (i guess we would probably need to take >> a few steps back in order to clear the way forward.) > >> Tough issues in my view and this should certainly not be seen as >> criticism to fedora- or refpolicy. I am just trying to highlight some of >> the issues i see, that make it hard(er) to build on both policies. > >> The initial thing i can do is refer to my custom branch that at least >> makes an initial attempt at solving these issues and even that is a work >> in progress and in its current shape far from my vision of how it should >> look (it requires a lot of time and a lot of hands-on experience in >> order to figure out how to best tackle particular issues. Some of which >> i was able to identify and others that i have yet to identify. > >> http://fedorapeople.org/gitweb?p=domg472/public_git/refpolicy.git;a=summary > > >>> selinux mailing list >>> selinux@xxxxxxxxxxxxxxxxxxxxxxx >>> https://admin.fedoraproject.org/mailman/listinfo/selinux > just pushed it here: http://git.fedorahosted.org/git/?p=selinux-policy.git;a=blobdiff;f=policy/modules/system/authlogin.if;h=ceadd0092afc825311e34ab099309561da7329da;hp=652110960f4d5b35b9ed187439ecac3a639b6b40;hb=afc9bf6c38c9eaafde0318927cc158f4f663f74d;hpb=7adc2a72c5665dd5506a8c214f189bcd910987a5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkz9FzYACgkQMlxVo39jgT99HACeIbW0R9oxupgmw0mp2/HpJ9Na EYAAnRzisEKGvqlAcHqL/pCz0b1tRLCb =U9Bv -----END PGP SIGNATURE----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
