[SSSD] Special HBAC rules

Dmitri Pal dpal at redhat.com
Wed Jul 28 19:54:05 UTC 2010


Simo Sorce wrote:
> On Wed, 28 Jul 2010 13:10:08 -0400
> Dmitri Pal <dpal at redhat.com> wrote:
>
>   
>> Hello,
>>
>> On a discussion about the UI for HBAC rules it occured to me that
>> there is a use case that we currently do not support with IPA<->SSSD.
>> I do not think it will be an issue for IPAv2 and SSSD 1.5 or but down
>> the road probably yes. So I want to put together a good description of
>> the feature into a trac ticket.
>> But I need to ask questions first, thus this email.
>>
>> The HBAC is good for the cases when a group of admins has access to
>> the group of the machines.
>> But those rules are not that good for the laptop use case.
>>
>> Effectively the access to any laptop will usually be controlled by the
>> two logical rules:
>> * Allow a group of admins to access a group of the laptops - this is
>> handled well with HBAC rules.
>> * Allow the owner of the laptop to access the laptop locally and
>> remotely. Hm... But how to express this without creating individual
>> rules for every user-laptop pair?
>>
>> Here is what comes to mind.
>> In the HBAC rule we have the concept of the hostCategory. Currently we
>> support only "All". But we can easily support the category "Laptop" or
>> "Personal Computer" to be more generic  and add a special string
>> attribute "hostPattern" that will contain a pattern that will allow to
>> match host name and the user name. By placing users and groups into
>> such rule we will effectively allow laptop users access to their own
>> machines.
>>
>> Here is the example:
>> my login name is dpal (short one) and dpal at redhat.com is long one. My
>> host name is dpal.laptop
>> So if I create an HBAC rule:
>>
>>  dn: ipaUniqueID=49af8430-cbed-11dd-ad8b-0800200c9a66, cn=hbac,...
>>  objectClass: top
>>  objectClass: ipaAssociation
>>  objectClass: ipaHBACRule
>>  ipaUniqueID: 49af8430-cbed-11dd-ad8b-0800200c9a66
>>  accessRuleType: allow
>>  memberUser: cn=dpal,cn=users,cn=accounts,...
>>  memberUser: cn=sgallagh,cn=users,cn=accounts,...
>>  memberUser: cn=ssorce,cn=users,cn=accounts,...
>>  memberUser: cn=ssbose,cn=users,cn=accounts,...
>>  memberUser: cn=Brnodev,cn=groups,cn=accounts,...
>>  memberService: cn=ssh,cn=hbacservices,cn=accounts,...
>>  hostCategory: laptop
>>  hostPattern: %short%.laptop
>>  ...
>>
>> This rule grants individual users listed above and Brno developers
>> access to the machines who's name starts with the short name of user
>> and has suffix ".laptop".
>>
>> The only drawback is that the admins would have to use some kind of
>> pattern for the personal machine names derived from the user name.
>> IMO this is a reasonable suggestion for those who want to start to
>> control access via HBAC rules, Potentially we can support several
>> patterns in one HBAC rule if there different naming conventions due
>> to acquisitions and other historical reasons.
>>
>> Thoughts?
>>     
>
> Pattern based matching looks extremely limiting and unusable in place
> (many) where machine naming rules and user naming rules are
> incompatible.
>   

I agree. This is why I ask.

> Also pattern matching locks one laptop to one user and if you want to
> move it to another user it requires you to unjoin it, change the name,
> and join again (or at the very least rename).
>
> Why not simply add a multivalued "owner" field in the machine object and
> have a way to express: "allow owner"
>   
This requires a bit more of the manual management and keeping the owner
attribute up to date but I guess that would work.
Assume we go with this approach then we will have an owner in the host
record. How we specify what the owner can actually do?
Should we have another mv attribute to point to the hbac service or hbac
service group in the host record?
If so how we prioritize the HBAC rules vs. access allowed through the
host record? Or if we do not add the service to the host record then how
we define HBAC rules around owners?


> The owner can also be a group.
>
> This way you can have one or more owners for a laptop as well (there
> are certainly cases where laptops are shared among very tiny groups
> anyways.
>
> Simo.
>
>   


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the sssd-devel mailing list