| Summary: | selinux policy for rtorrent-0.8.9 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Vincent Brillault <gentoo> |
| Component: | SELinux | Assignee: | Sven Vermeulen (RETIRED) <swift> |
| Status: | VERIFIED FIXED | ||
| Severity: | enhancement | CC: | selinux |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | sec-policy r6 | ||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Module main rules
Module interfaces Module file context rules Simple ebuild (contains elogs for setting correctly the port) |
||
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 |
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.