[Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs

[Simo Sorce]

On Fri, 2014-06-13 at 14:29 -0400, Rob Crittenden wrote:
> Rob Crittenden wrote:
> > Simo Sorce wrote:
> >> On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote:
> >>> 0001
> >>>
> >>> When is_allowed_to_access_attr() fails it should include the value of
> >>> access in the error log for debugging.
> >>
> >> Ok added more detailed logging
> >>
> >>> Nit: Coluld not fetch REALM backend
> >>
> >> Fixed
> >>
> >>> There are still a ton of "ber_scanf failed" duplicated fatal errors. I'm
> >>> fine keeping a common err_msg but the fatal error should be unique.
> >>
> >> Yeah thanks to this comment, I had a small change of heart.
> >> Instead of sending such detailed information to clients I reverted to
> >> send a little less information to the clients and instead LOG_FATAL in a
> >> more detailed way. HTH
> >>
> >>> This breaks normal host delegation. If you add a host to another host's
> >>> managedby, getting the keytab will fail. This is due to:
> >>>
> >>> [11/Jun/2014:16:56:45 -0400] NSACLPlugin - conn=4 op=3 (main): Deny
> >>> write on
> >>> entry(fqdn=client2.example.com,cn=computers,cn=accounts,dc=example,dc=com).attr(ipaProtectedOperation;write_keys)
> >>> to fqdn=client1.example.com,cn=computers,cn=accounts,dc=example,dc=com:
> >>> no aci matched the subject by aci(97): aciname= "Groups allowed to
> >>> create keytab keys", acidn="cn=accounts,dc=example,dc=com"
> >>
> >> Ok this should be working now, I added a new ACI to allow also
> >> managedby#USERDN to operate on keytabs.
> >>
> >> New patches attached.
> > 
> > Functionally these seem to work ok. I think there should be some
> > documented way to enable the -r in ipa-getkeytab. Right now I'm not even
> > entirely sure how one would add a permission to do so.
> 
> NACK
> 
> Simo noticed that the ACIs are in cn=accounts. On the one hand this is a
> reasonable place to put these, on the other it is a bit broad.
> 
> I think we'll need type-specific ACIs in a number of subtrees: users,
> computers and services.

[Only patch 3 attached, as none of the others changed, and addiotional
discussion is needed, see below.]

Ok after looking carefully into this problem I see that there are really
2 issues.
1) managedby for users, we do not want someone adding a managedby
attribute to inadvertently allow the manager to set a user's password.

So I changed that ACI and restricted it only to ipaHost and ipaService
objects (tested).

I haven't touched any other ACI because in order to use them you need to
have intentionally added an ipaAllowedToPerform attribute to the user
entry.

2) and I think this is a MUCH bigger issue, the Admin users are
unbounded and pass any Access Control Check and this means they can now
retrieve any key for users or machines.
It is already bad enough that admins can unconditionally set any key,
but this at least leaves back a pretty big trail (the original client
password/key fails to work), and is a necessary evil (password resets,
hosts creation/recovery).
But I am not very comfortable with the idea an admin can retrieve any
key without actually ending up changing it. Petr do we have any short
term plan to address the Admin's super ACI ?

Otherwise we can add ipaProtectedOperation in the exclude list for the
superACI ("Admins can manage any entry") and add the following ACI in
cn=accounts, to restore admin ability to set keys (but not retrieve
them):

aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl
 "Admins are allowed to rekey any entity"; allow(write) groupdn="ldap
 :///cn=admins,cn=groups,cn=accounts,$SUFFIX";)

I tested this combination and it effectively stops admin from retrieving
all keys unless explicitly authorize by positive
ACIs/ipaAllowedToPerform attributes.


Thoughts ?

-- 
Simo Sorce * Red Hat, Inc * New York
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-keytab-Add-new-extended-operation-to-get-a-keytab.patch
Type: text/x-patch
Size: 27981 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140613/a8753d6b/attachment.bin>