> Could you please test my policy and provide feedback to that it can be
> extended?
>
Sure will do, but you ask me to use it on a "clean" Fedora 14 - I do not
have that! I backtracked of FC14 months ago as I was not happy with a
lot of things in that release, so I am now using FC13 with parts build
(understand compiled from source) from FC14 and the rawhide repository.
If you are happy with this arrangement let me know and I will test this.
> There are some things to be noted:
>
> The policy support a default setup. That is to say:
>
> transmission-daemon-2.11-2.fc14.x86_64
>
> No changes have been made. I just installed it and ran it.
>
> Can you please do the same?
>
Sure will do (provided you are happy with the system setup I have). I
take it v2.12-2 is the latest version available from the FC repository,
is that right? There is a newer (stable) version available - 2.22, so I
am not sure whether you would want to try this out (I have also
customised a .spec file which installs 2.22 - this is what I use here
and could attach this .spec file, if desired).
> Here is my policy:
>
> 1. Add to corenetwork.te.in:
>
> network_port(bittorrent_ctl, tcp,9091,s0)
>
> I have not yet dealt with any other ports/connections. I would like to
> see raw AVC denials of that if possible.
>
That's OK, but there will be *a lot* of them!
> - -- a: bittorrent.te:
>
> policy_module(bittorrent, 1.0.0)
>
> ########################################
> #
> # Declarations
> #
>
> ## <desc>
> ## <p>
> ## Allow bittorrent servers to use cifs
> ## used for public file transfer services.
> ## </p>
> ## </desc>
> gen_tunable(allow_bittorrentd_use_cifs, false)
>
> ## <desc>
> ## <p>
> ## Allow bittorrent servers to use nfs
> ## used for public file transfer services.
> ## </p>
> ## </desc>
> gen_tunable(allow_bittorrentd_use_nfs, false)
>
> type bittorrentd_t;
> type bittorrentd_exec_t;
> init_daemon_domain(bittorrentd_t, bittorrentd_exec_t)
>
I see you have removed the NAT-PMP/uPNP tunable. Any reason for that?
> corenet_all_recvfrom_unlabeled(bittorrentd_t)
> corenet_all_recvfrom_netlabel(bittorrentd_t)
> corenet_tcp_sendrecv_generic_if(bittorrentd_t)
> corenet_udp_sendrecv_generic_if(bittorrentd_t)
> corenet_tcp_sendrecv_generic_node(bittorrentd_t)
> corenet_udp_sendrecv_generic_node(bittorrentd_t)
> corenet_tcp_bind_generic_node(bittorrentd_t)
> corenet_udp_bind_generic_node(bittorrentd_t)
>
Yeah, that's the part I wanted to enclose last night, but thought
against it.
> - -- b: bittorrent.if:
>
> ## <summary>Bittorrent peer-to-peer communications protocol for file
> sharing.</summary>
>
> ########################################
> ## <summary>
> ## Read bittorrent daemon
> ## configuration files.
> ## </summary>
> ## <param name="domain">
> ## <summary>
> ## Domain allowed access.
> ## </summary>
> ## </param>
> #
> interface(`bittorrent_read_daemon_config_files',`
> gen_require(`
> type bittorrentd_etc_t;
> ')
>
> files_search_etc($1)
> allow $1 bittorrentd_etc_t:file read_file_perms;
> ')
>
Interesting! So, there is no need for the domain transition present in
my version then?
> - -- c: bittorrent.fc:
>
> /etc/sysconfig/transmission-daemon --
> gen_context(system_u:object_r:bittorrentd_etc_t,s0)
>
> /usr/bin/transmission-daemon --
> gen_context(system_u:object_r:bittorrentd_exec_t,s0)
>
I think this should be left to /usr/bin/transmission-* as there are
other transmission-* executables as part of that package which are used
(and there are even more in the 2.22 version).
> Please compare what i have to what you have and ask questions about why
> my implementation differs from yours.
>
My main query is fundamentally around the "#!" remarks from my version
of the policy, mainly the NAT-PMP/uPNP access - it is disabled in your
version of the policy, so I presume you would like to see AVCs first
before you decide whether it is worth including this. If it is left
disabled, this will severely limit the ability of the daemon to operate
(particularly if executed in a vpn or closed-network environment).
> Here are a few basic comments:
>
> 1. i named the policy module bittorrent instead of transmission. This is
> because there are many bittorrent servers i suspect. This class of
> servers have similar properties and so it makes sense to group them all
> in a single bittorrent domain.
>
The problem I see with that is that even though there are a plethora of
bittorrent clients out there they are all very different and operate
very differently. Shoving them all in under the same domain is a
mistake, I think, as they all have different ways in which they operate
(and that includes port usage, capabilities etc).
> 2. I have labelled /etc/sysconfig/transmission-daemon: This is required
> to make any bittorrent_admin functional. We want bittorrent_admin to be
> able to define bittorrent server arguments (edit
> /etc/sysconfig/transmission-daemon)
>
I am not sure I understand this. Transmission has its own configuration
file, which is generated at startup (if it cannot find an existing one)
and this file is modified during set-time intervals while the daemon is
running. It is also modified (to include the latest "version" of its
settings - by web/gui clients connecting to the daemon, for example)
when the daemon exits. These settings are normally stored in
{TRANSMISSION-HOME}/.config/transmission-daemon/settings.json, so I do
not see the need for /etc/sysconfig.
> 3. The transmission-daemon package installs only the following files:
>
> /etc/rc.d/init.d/transmission-daemon
> /etc/sysconfig/transmission-daemon
> /usr/bin/transmission-daemon
> /usr/share/man/man1/transmission-daemon.1.gz
> /var/lib/transmission
>
> The /etc/rc.d/init.d/transmission-daemon script defines
> /var/log/name.log to be the default log file location. Yet there is no
> log file location specified in the "server args". This seems to be a
> bug, but it does not have to be if transmission-daemon logs to /var/log
> by default without setting the log server arg.
>
Interesting observation. I must have modified the original init.d script
then because I do not recall transmission using a separate log file -
only the syslog. What do you mean by "server args"?
> I only started and stopped the server, and it did not create any log files.
>
You need to modify settings.json to include message level 2 (or above)
to see anything in the logs (the default is 1, which only outputs
anything if there is a system/program error, I think).
> 4. The transmission-daemon lock and pid file are created by the init
> script and not by transmission-daemon.
>
Yeah, that is correct.
> 5. The default location for transmission-daemon content appears to be
> /var/lib/transmission. The transmission-daemon created files and
> directories below there (.config/transmission-daemon.*). I seems that
> bittorrent_admin is expected to put the torrent content in the
> applicable layers below that directory as i understand it.
>
That is correct - it is the same as with tor, no difference.
> Please try out my version of the policy on a clean and unmodified Fedora
> 14+ transmission-daemon installation, and provide feedback.
As I already pointed out above - that would be problematic as I do not
use (nor do I intend to) FC14 - I am still on (modified) FC13, so if
this would be a problem let me know.
> Raw AVC
> denials are preffered.
>
That is a given! Many thanks for reviewing this.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
