[Freeipa-devel] Draft: Read permissions for user

[Petr Viktorin]

On 04/16/2014 03:41 PM, Simo Sorce wrote:
> On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote:
>> On 04/15/2014 04:55 PM, Petr Viktorin wrote:
>>> Hello,
>>> At Devconf, we decided what most of the default read permissions should look
>>> like, but we did not get to user.
>>> Here is a draft of 4 read permissions. Please comment.
>>>
>>>
>>> Basic info (anonymous):
>>> [top]
>>>      objectclass
>>> [person]
>>>      cn, sn, description
>>> [organizationalPerson]
>>>      title
>>> [inetOrgPerson]
>>>      uid
>>>      displayName, givenName, initials
>>>      manager
>>> [inetUser]
>>>      memberOf
>>
>> <== We originally specifically hidden memberOf attribute from anonymous users.
>> I think we should continue hiding it.

OK

>>> [ipaObject]
>>>      ipaUniqueID
>>> [ipaSshUser]
>>>      ipaSshPubKey
>>> [ipaUserAuthTypeClass]
>>>      ipaUserAuthType
>>> [posixAccount]
>>>      gecos, gidNumber, homeDirectory, loginShell, uidNumber
>>>
>>>
>>> Details (all authenticated):
>>> [person]
>>>      seeAlso, telephoneNumber
>>> [organizationalPerson]
>>>      fax, l, ou, st, postalCode, street
>>>      destinationIndicator, internationalISDNNumber, physicalDeliveryOfficeName,
>>>          postalAddress, postOfficeBox, preferredDeliveryMethod,
>>>          registeredAddress, teletexTerminalIdentifier, telexNumber, x121Address
>>> [inetOrgPerson]
>>>      carLicense, departmentNumber, employeeNumber, employeeType,
>>>          preferredLanguage, mail, mobile, pager
>>>      audio, businessCategory, homePhone, homePostalAddress, jpegPhoto,
>>>          labeledURI, o, photo, roomNumber, secretary, userCertificate,
>>>          userPKCS12, userSMIMECertificate, x500UniqueIdentifier
>>> [inetUser]
>>>      inetUserHttpURL, inetUserStatus
>>> [ipaUser]
>>>      userClass
>>
>> I would personally not divide the attributes as basic and detailed. IMO it is
>> our artificial distinction and may vary between deployments. Why would we for
>> example show inetUserHttpURL to authenticated only and ipaSshPublicKey to everyone?

I thought it would be helpful to have a distinction between what needs 
anonymous read, and what's optional.

I can move individual attributes, of course.

>> My proposal would be to have a permission "Read User Information" for all
>> attributes above.

This way a paranoid admin would need to go through the attributes one by 
one to decide what needs to stay anonymous and what doesn't. Having two 
permissions makes this easier to tune.

But of course I can merge them.

>>> Kerberos/login-related (all authenticated):
>>> [krbPrincipalAux]
>>>      krbPrincipalName, krbCanonicalName, krbPrincipalAliases,
>>>      krbPrincipalExpiration, krbPasswordExpiration, krbLastPwdChange
>>> [+]
>>>      nsAccountLock
>>
>> Ok. So permission "Read User Kerberos Attributes"?

OK

>>> Kerberos-related (user admins only):
>>> [krbPrincipalAux]
>>>      krbLastSuccessfulAuth, krbLastFailedAuth, krbLastPwdChange
>>
>> So permission "Read User Kerberos Login Attributes"?

OK

>> I think this group should also have:
>>
>> krbLastAdminUnlock
>> krbLoginFailedCount
>
> +1
>
>>> No read permission:
>>> [person]
>>>      userPassword
>>
>> ok
>>
>>> [krbPrincipalAux]
>>>      krbPrincipalKey, krbExtraData, krbPwdHistory
>>
>> ok
>>
>>>      krbLastAdminUnlock,
>>
>> Move this one.
>>
>>>      krbLoginFailedCount
>>
>> Move this one.
>>
>>> krbPrincipalType
>>
>> Simo? I know we do not user this attribute, but wouldn't it fit in "Read User
>> Kerberos Attributes" permission?
>
> Yes, we do not use it yet, but we may want to in the future.
>
>>> krbPwdPolicyReference
>>
>> This could contain DN to user's password policy attribute. IMO somebody should
>> have a right to read it. Simo, should all authenticated users be able to read it?
>
> Probably not. In another thread we are trying hard to conceal password
> policy objects, showing this to everybody would thwart that effort as
> you'd be able to find out the objects by querying all the ones that
> reference them. Admin and Help Desk people would need access to it
> though as they need to be able to inspect and change this attribute.
>
>>>          krbTicketPolicyReference, krbUPEnabled
>>
>> I would treat those the same as krbPwdPolicyReference.
>
> Yeah, makes sense.
>
>>> [krbTicketPolicyAux]
>>>      krbMaxRenewableAge, krbMaxTicketLife, krbTicketFlags
>>
>> Ok. This will be readable by people with "System: Read User Kerberos Ticket
>> Policy" permission.
>>
>>> [mepOriginEntry]
>>>      mepManagedEntry
>>
>> This is used to bind user to it's private group. We use it for example in
>> group-detach command to distinguish between managed and non-managed groups.
>>
>> We may want to show it to all authenticated users.
>
> Do we need to ?
> It is only interesting for internal/administrative operations.
>
> Simo.
>


-- 
Petr³