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

Pavel Reichl preichl at redhat.com
Fri Dec 5 09:28:34 UTC 2014


On 11/13/2014 12:24 PM, Pavel Reichl wrote:
>
> On 06/04/2014 07:49 PM, Pavel Reichl wrote:
>> On Wed, 2014-06-04 at 16:11 +0200, Jakub Hrozek wrote:
>>> On Wed, Jun 04, 2014 at 09:58:20AM +0200, Sumit Bose wrote:
>>>> 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
>>> OK, that sounds like a far compromise. I also hope noone would use the
>>> deny list then. Thanks!
>>> _______________________________________________
>>> sssd-devel mailing list
>>> sssd-devel at lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>> Hello,
>> new patches are attached.
>>
>> 1st patch:
>> I amended the debug messages as Stephen suggested.
>> Non-existing objects are ignored on allow lists, but imply access denied
>> on deny lists.
>>
>> 2nd patch:
>> amended mam page - documenting missing objects from deny lists.
>>
>> 3rd patch:
>> Minor optimization - don't continue matching username with names from
>> simple_allow_list after successful match.
>>
> I have rebased 1st and 3rd patch as there are users who might benefit 
> from the changes immediately.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
BUMP - there's a BZ requesting this patch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20141205/9501d52e/attachment.html>


More information about the sssd-devel mailing list