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] Module interfaces
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. Some remarks: - 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 programs ? - 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