[systemd-devel] Patch for Smack labelling support in udev

[Kok, Auke-jan H]

On Thu, Sep 12, 2013 at 10:23 AM, Kay Sievers <kay at vrfy.org> wrote:
> On Fri, Aug 9, 2013 at 8:56 PM, Kok, Auke-jan H
> <auke-jan.h.kok at intel.com> wrote:
>> On Wed, Jul 24, 2013 at 3:15 AM, Reshetova, Elena <elena.reshetova at intel.com> wrote:
>
>>> For example, I can set a couple of smack-related xattrs in one go like
>>> XATTR{security.SMACK64}="*", XATTR{security.SMACK64EXEC}="*".
>>> Doesn't make sense from smack point of view (only smack64 is really meaningful
>>> on device nodes), but proves that functionality works.
>>
>> right, but we could be setting other non-SMACK xattrs now all in one
>> go - for example, SELINUX ones ("security.selinux").
>
> Yeah, *looks* powerful, but also scary. :)
>
> And selinux is not managed by visible strings exposed to tools, it's
> all hidden in a library, and the database returns the stuff to apply.
> There should never be the need to set any string from selinux with a
> tool carrying static strings.
>
>> This looks OK to me, can you take another look at it?
>
> I still can't wrap my head around the issue that we can use udev rules
> now to *add* things which will never get removed again. If we add a
> rule that set one of these attributes, and remove the rule again, the
> applied xattr will never be cleared.
>
> It all sounds not right to me, and I don't think we should go ahead
> with anything like this before we have sorted out the responsibilities
> and ownership of data we attach to device nodes. We do not do that for
> anything else, things just don't pile up, they are reset, cleared when
> the config goes away and an event is triggered.
>
> We probably need some concept of ownership, based on xattr names or
> namespaces, soemthing that  makes it clear who's responsible to
> reset/clear the attributes when the config changes.
>
> Not sure, maybe we can just reset all xattrs with an "add" event, and
> declare "add" as a form of reset to a prisitine state.
>
> The other issue is, that as nice as generic support for xattrs sounds,
> it might in the end not be what we should offer to "random" users.
>
> I really can't decide at this moment, I have to think it through.

well, for Tizen at least, we need this functionality. Too many nodes
appear in /dev/ that should only be accessible by certain services
alone, and this is exactly what SMACK adds.

A good example is that SMACK allows us to grant only camera
(/dev/video/*) privileges to approved camera applications, instead of
having every application for a user in a session have full access to
the camera. We get the best of both access control methods.

I realize that unsetting/removal is a concern, but I don't think it
should preclude merging code that is better at setting/adding :^)

The only alternative I see is to create another udev event listener
and have that process set smack labels. That would just duplicate a
lot of udev code... And it still doesn't solve the removal of rules -
that would be something only a e.g. %post script could consistently
do.

Auke