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

[Reshetova, Elena]

-----Original Message-----
From: Colin Walters [mailto:walters at verbum.org]
Sent: Wednesday, May 08, 2013 4:14 PM
To: Reshetova, Elena
Cc: systemd-devel at lists.freedesktop.org; Schaufler, Casey; Ware, Ryan R
Subject: Re: [systemd-devel] Patch for Smack labelling support in udev

>On Wed, 2013-05-08 at 11:16 +0000, Reshetova, Elena wrote:

>> The functionality and reasoning is inside. I will be happy to answer
> any questions.

>Why is this different from how SELinux works?   There from what I can
>see there's a centralized API to look up the expected label for a given 
>filename (selabel_lookup_raw), and then set the target label for newly 
>created files in the current thread (setfscreatecon).  That way we're 
>ensuring the file is created atomically with that label.

>So why is is SMACK different here, and could it fit into what already exists 
>in src/shared/label.c ?

I am not an expert in SELinux, but my understanding is that SELinux has a 
central place (or a number of central places) to store the security policy and 
then can lookup the needed label from it based for example on filename.
Smack is different in a sense that there is no common policy to store info 
about path:label matching. This info is stored for files in xattrs (mostly 
security.smack64) and for separate userspace components
it is stored with the component (like dbus policies can be stored in dbus 
config files). So, there is no central place to fetch the info what kind of 
label each device node should get. It seems to me that the natural place for 
udev would be
the rules file since it already has other security attributes there defined 
and we can follow the same style and construction.

Best Regards,
Elena.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7220 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20130508/73f00b71/attachment.bin>