-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkz8/q4ACgkQMlxVo39jgT+YTgCfaoeLHDrzGAigGCEdtbhzVzsJ YxQAn0NoRldVoSB7DRgfCmQS58Mn8nWk =kTSm -----END PGP SIGNATURE----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
