-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 > - -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux Dominick I meant the changes for openct running on authlogin. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkz9FfQACgkQrlYvE4MpobOTXgCgnnn8Ik3INbxPwbfePMvZDT2c C/oAoI8joyqoFkRLR53GT5KtXbSfgZZx =tqbi -----END PGP SIGNATURE----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
