Clarification on the imply annotation

[chinmoy ranjan]

On Mon, May 15, 2017 at 8:40 PM, Miloslav Trmac <mitr at redhat.com> wrote:

> 2017-05-15 16:56 GMT+02:00 chinmoy ranjan <chinmoyrp65.gsoc at gmail.com>:
>
>> > From the above description, though, I would recommend thinking about
>> whether the different actions your KIO backend are actually distinct
>> privileges; e.g. copy/symlink/rename are very likely equivalent in power
>> (they allow the user to become unrestricted root), so there is little point
>> in separating them.
>> >
>> > And if you are considering using the “imply” annotation to allow all of
>> the actions whenever any one is authorized, well, then they are
>> structurally equivalent. It seems much simpler to me to have a single
>> “modify the filesystem in arbitrary ways” action shared for all of the
>> operations, making “imply” completely unnecessary.
>> >
>> > Or, perhaps, at most, one “read anything” action and one “read and
>> modify anything” action, with the read-write one implying the read-only one
>> (but not the opposite).
>> >
>>
>> My initial plan was to have one single action to perform all of the file
>> handling operations. But after bit of discussion with my mentor I decided
>> upon giving the  user more fine-grain control. So instead of one generic
>> action that can be easily enabled or disabled, the user can now control
>> which action gets privilege, like one can create new files but can't delete
>> them or a user can rename files owned by root but can't perform any other
>> operation.
>>
>> Any thoughts on this?
>>
> Would that *actually* be more granular if any of the actions were
> root-equivalent? If it weren’t more granular, asking the users to do extra
> work per action would be just wasted, and pretending to users that the
> granularity matters could make them make incorrect security assumptions and
> think they are secure when they weren’t.
>
> And as I said, if the “imply” relations actually made all of the actions
> equivalent, there would be *no effective granularity anyway*. The “imply”
> relations *cannot be overridden by an administrator* in the .rules files,
> at least not directly. Perhaps .rules can still affect the authorization of
> those actions, but if you want to rely on that in the design, *you* need
> to figure out how it works and whether it is sufficient in the use case.
>
> IMHO, if there is any granularity to be had, it is not rename/delete; it
> is either the coarse read/write one, or ideally a system where the
> privileged access can be granted only to specific subdirectories — but
> polkit is fairly unsuitable for such an open-ended granularity, and
> per-directory access can be given using ACLs anyway, so polkit is
> unnecessary for that.
>     Mirek
>

Thanks for the input. I will rethink my approach. Also the previous was
supposed to be sent to the mailing list and cc'ed to you. Looks like
something went wrong :( .

Regards,
Chinmoy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/polkit-devel/attachments/20170515/37175a79/attachment.html>