Hi list
While updating my previous domain definition for the mutt e-mail application
(as well as working on a whole lot of other user application domains) I got
more and more into contact with the user-content categorical stuff. We had a
few discussions on it earlier as well, and Dominick also helped me out
investigating all this on #selinux.
In short, user directories have a few locations that are not really /user/
content, but more /user application/ content. This includes of course the
configuration files of user applications, specific data locations and
caches. The freedesktop project [1] has also tried to get these locations
better defined, and created the "XDG Base Directory Specification" [2] from
which I am devising this RFC.
[1] http://www.freedesktop.org/wiki/
[2] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
My initial idea is to support these XDG locations within the SELinux policy,
by creating types such as
- xdg_data_home_t ~/.local/share
- xdg_config_home_t ~/.config
- xdg_cache_home_t ~/.cache
The userdomain definition would then have read/manage interfaces on these
types. Of course, the types themselves are fully manageable by the user
domains themselves.
The advantage of such an approach would be that many domain definitions do
not require userdom_manage_user_home_content_* privileges anymore in the
majority of cases. Also, by destinguishing the types (data, config, cache)
it is also simpler to define the rights. The downside is that quite a few
domains will need to be updated to reflect this, but that shouldn't be a
reason for not doing things ;-)
I do have a couple of questions on this approach though...
1/ Would it be wise to reuse these types?
A prime example: vim, which most likely never needs its own domain, "caches"
information in a ~/.viminfo file. Although this file acts like a cache, it
isn't a file for the XDG specification. Yet I personally mark this file as
xdg_cache_home_t and have all domains that run vim (slrn, mutt) use
userdom_manage_xdg_cache_home().
On one side, I think that is allowed, since the purpose of the type is the
same. But perhaps I shouldn't call the types xdg_* but rather user_*
instead?
2/ Would it be wise to mark HOME_DIR/\.??* as xdg_config_home_t?
Almost all files in a users' home directory that are prepended with a period
are used for configuration purposes. There are exceptions of course, but I
have the impression that these exceptions are managed by their own domains
anyhow. Since HOME_DIR/\.??* is a very generic expression, every module that
defines something with a regular expression "later" than the second position
in the name (say HOME_DIR/\.vnc(/.*)?) will win the file context anyhow.
Wkr,
Sven Vermeulen
On Tue, Aug 23, 2011 at 12:22:54PM +0200, Sven Vermeulen wrote:
> Hi list
>
> While updating my previous domain definition for the mutt e-mail application
> (as well as working on a whole lot of other user application domains) I got
> more and more into contact with the user-content categorical stuff. We had a
> few discussions on it earlier as well, and Dominick also helped me out
> investigating all this on #selinux.
>
> In short, user directories have a few locations that are not really /user/
> content, but more /user application/ content. This includes of course the
> configuration files of user applications, specific data locations and
> caches. The freedesktop project [1] has also tried to get these locations
> better defined, and created the "XDG Base Directory Specification" [2] from
> which I am devising this RFC.
>
> [1] http://www.freedesktop.org/wiki/
> [2] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
>
> My initial idea is to support these XDG locations within the SELinux policy,
> by creating types such as
> - xdg_data_home_t ~/.local/share
> - xdg_config_home_t ~/.config
> - xdg_cache_home_t ~/.cache
The locations and file types mentioned above look good to me. I agree with those
The should probably be a separate xdg module as these locations are not destkop-environment specific. Fedora defined these types in the gnome module which i think is not optimal, because these xdg paths are not specific to just gnome.
There are some things to consider though. first and foremost labeling. it is the user domain (or user application domains if the path doesnt exist when the user application needs it) that creates these paths. User domains by default create objects in $HOME with type user_home_t. which is as it should be.
So for this to work currently (except in > fedora 16) one would have to depend on restorecond -u running in the desktop session or one would have to add these paths to /etc/skel (the user home directory gets restored after files are copied from /etc/skel)
Both above options are ugly to say the least.
In Fedora 16 and above we can define named file transitions. This would allow use to specify: if userdomain creates a dir with name ".cache" in a dir with type user_home_dir_t; then type transition to xdg_cache_home_t. That would solve the labeling issue described above.
>
> The userdomain definition would then have read/manage interfaces on these
> types. Of course, the types themselves are fully manageable by the user
> domains themselves.
we would just allow the login user domains access to manage and relabel "xdg_home_content" e.g. xdg_cache_home_t, xdg_data_home_t and xdg_config_home_t.
something like "xdg_manage_home_content() and xdg_relabel_home_content()" then just call that by "unpriv_userdomain" in userdom_restricted_user_template() ( or something allow those lines ) we could also create a "userdomain_prefixed xdg_per_role_template if that would make sense and just 'allow $3 xdg_home_content:dir { relabel_dir_perms manage_dir_perms; ') and same for files.
>
> The advantage of such an approach would be that many domain definitions do
> not require userdom_manage_user_home_content_* privileges anymore in the
> majority of cases. Also, by destinguishing the types (data, config, cache)
> it is also simpler to define the rights. The downside is that quite a few
> domains will need to be updated to reflect this, but that shouldn't be a
> reason for not doing things ;-)
The issue isnt so much access to generic user home content. Many application require this access anyway. for example mutt sending an enclosed attachment ( example a picture from ~/Pictures ).
It should not be our main priority to protect generic user home content, but rather protect the integrity of user applications and user application content (such as user app configuration, user app secrets etc)
> I do have a couple of questions on this approach though...
>
> 1/ Would it be wise to reuse these types?
>
> A prime example: vim, which most likely never needs its own domain, "caches"
> information in a ~/.viminfo file. Although this file acts like a cache, it
> isn't a file for the XDG specification. Yet I personally mark this file as
> xdg_cache_home_t and have all domains that run vim (slrn, mutt) use
> userdom_manage_xdg_cache_home().
No, in my view. if vi runs in the user domain and creates whatever content in ~/.viminfo than this file is to be created with type user_home_t.
If you decide to confine vim, then you can create your own vim private type for ~/.viminfo "vim_home_t?" and allow your vim domain to userdom_user_home_dir_filetrans(vim_t, vim_home_t, file), when we have named file transitions you can make that even more specific.
> On one side, I think that is allowed, since the purpose of the type is the
> same. But perhaps I shouldn't call the types xdg_* but rather user_*
> instead?
its not xdg content because its not using the xdg paths. its user_home_t.
xdg types should imho be declared in the xdg module and be prefixed with xdg.
> 2/ Would it be wise to mark HOME_DIR/\.??* as xdg_config_home_t?
no.
> Almost all files in a users' home directory that are prepended with a period
> are used for configuration purposes. There are exceptions of course, but I
> have the impression that these exceptions are managed by their own domains
> anyhow. Since HOME_DIR/\.??* is a very generic expression, every module that
> defines something with a regular expression "later" than the second position
> in the name (say HOME_DIR/\.vnc(/.*)?) will win the file context anyhow.
no xdg content is in the xdg paths. that what the xdg spec is about.any thing not below any xdg path is not xdg content. That not to say that you cannot give it a private type, sure you can if you decide to confine the app creating content, but its not xdg content.
> Wkr,
> Sven Vermeulen
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110823/28fd9847/attachment-0001.bin