Created attachment 322466 [details]
Module main rules
I've built a SELinux module for running rtorrent in strict mode. Seems to work fine with current rtorrent stable version 0.8.9 running inside a screen and without xmlrpc (I have been using it for some months now).
I created a rtorrent_tcp_port_t but that could be replaced by rights to listen on any port for simplicity.
Created attachment 322468 [details]
Created attachment 322470 [details]
Module file context rules
Created attachment 322472 [details]
Simple ebuild (contains elogs for setting correctly the port)
I'm integrating it in our repository and will submit it upstream as well soon.
A few comments:
(0.) rtorrent_conf_t will most likely be named rtorrent_home_t.
Most HOME_DIR/* stuff is labeled with _home_t, whereas /etc/* stuff is _conf_t or _etc_t. As you defined it for a ~/.rtorrentrc item, I think rtorrent_home_t is more applicable.
(1.) I'm probably going to drop rtorrent_download_t in favor of xdg_downloads_home_t
We're working on an XDG-supporting policy, which includes the generic user directories for downloads, music, ... I'm not sure refpolicy (upstream) accepts this (they're more into having all user files to remain labeled user_home_t) but I'm definitely going further with this for Gentoo.
So I'm probably going to allow rtorrent_t to manage xdg_downloads_home_t content, unless you think it's better to have a separate type for this? In any case, users need to be able to relabel their content as such, so you'd need to allow relabel rights anyway.
(2.) Using rtorrent_port_t
I generally don't make any separation between the udp port and tcp port types. Otherwise this policy would be the first to do so.
If you have hardened-dev overlay, you should be able to remove your local rtorrent policy from memory and use the live policy ebuild to test the policy out further.
In hardened-dev, r6 release
Your policy looks great.
- After thinking about it, I'm not sure if the port name is apprioriate: it will probably collide with other BitTorrent clients, perhaps a more generic name
would be better
- Are there some location marked 'xdg_downloads_home_t' by default ? Wouldn't using this type give right to rtorrent to manage things downloaded by other
- Would it be possible to add some warnings in the ebuild ? (Users need to define the tcp ports and to use xdg_downloads_home_t directories)
I'm currently using your policy (with a single change: I don't use xdg_downloads_home_t as I don't understand its consequences) without problems so far :)
Is the port generic for bittorrent?
Also, on the xdg_downloads_home_t, you're correct (but on the other hand, using general user_home_t has even more consequences on this). We could look at supporting specific download types, but I don't think that would be very much manageable...
In main tree, ~arch'ed
r8 is now stable