avc: smartcard token login

[Daniel J Walsh]

-----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 at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
> 
- --
selinux mailing list
selinux at lists.fedoraproject.org
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-----