[SSSD] [PATCH] simple access provider - don't fail on non-existing objects

Sumit Bose sbose at redhat.com
Wed Jun 4 07:58:20 UTC 2014


On Wed, Jun 04, 2014 at 08:42:21AM +0200, Jakub Hrozek wrote:
> On Tue, Jun 03, 2014 at 04:22:51PM -0400, Simo Sorce wrote:
> > On Tue, 2014-06-03 at 15:52 -0400, Stephen Gallagher wrote:
> > > On 06/03/2014 08:26 AM, Pavel Reichl wrote:
> > > > Hello,
> > > > 
> > > > I noticed that if using simple access provider and having
> > > > non-existing group or user in access/deny list then access will be
> > > > denied and "su: System error" will be printed.
> > > > 
> > > > I think it's OK to simply skip non-existing objects on allow_list.
> > > > 
> > > > I'm not so sure what to do in case of deny lists. Should we also
> > > > just skip them or should we deny the user and print more
> > > > appropriate message ("su: Permission denied")?
> > > 
> > > 
> > > I agree that skipping (and logging) on allow lists is fine.
> > > 
> > > For deny lists, it implies that either 1) the admin typoed the
> > > user/group name in the list or 2) that the user/group was removed from
> > > LDAP.
> > > 
> > > In the first case, we're potentially dealing with privilege leakage
> > > (someone who shouldn't have access has it due to an admin
> > > misconfiguration). In the second case, this is perhaps just normal
> > > operating changes and shouldn't require client modification.
> > > 
> > > As I type this, I become more certain that the correct approach here
> > > should be to log this with a better message (in both
> > > SSSDBG_CRIT_FAILURE and sss_log) and just proceed as if it didn't exist.
> > > 
> > > A better message would perhaps be:
> > > "The [user|group] %s does not exist. Possible typo in
> > > simple_[allow|deny]_[users|groups]"
> > 
> > The secure thing to do is to fail, because you do not know with
> > certainty who should be allowed.
> 
> So if an admin typoes a group, noone can log in? That might effectivelly
> lock out legitimate access that would subsequently use sudo vi to fix the
> typo..

I think we can skip with a log message in the allow case because then
access is still only allowed if another entry matches.

In the deny case I would prefer a reject as well. With this we would
make the allow list more comfortable to use and people might rethink
their deny list usage in environments where groups are often deleted or
renamed.

bye,
Sumit

> 
> > 
> > Deny lists should simply not be used but we fell again in the trap and
> > now we need to act accordingly.
> > 
> > Simo.
> > 
> > -- 
> > Simo Sorce * Red Hat, Inc * New York
> > 
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list