-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/29/2011 03:02 PM, Mr Dash Four wrote:
> 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.
Sure, but can you at least see if you can install the
transmission-daemon-2.11-2.fc14.
There may be some differences between the f13 and f14 edition.
> 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).
I would rather, you use Fedora's spec file. If you are able to package
2.22 using fedoras' 2.11-2 spec file then that would be fine.
> 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!
i bet, i do not need to see each denial though, just the ones that are
unique ;)
> - -- 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?
Not that i am aware of, no
> - -- 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).
No those seem to be client apps and helper apps.
> 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).
My policy is imcomplete because i only tested starting and stopping the
services. I never got to the point of what you mention above.
So please provide feedback (avc denials) after testing and we will
extend policy to allow the access.
> 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).
We can at least group the ones that do have a lot in common. Since this
is the first bittorrent policy we for now are best to name it bittorrent
instead of transmission.
> 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.
yes and it also installs /etc/sysconfig/transmission-daemon , which
incidentally is what is being used in the init script. (which is
confirmed by initrc_t needing access to read bittorrent_etc_t files.)
> 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"?
Well you obviously added policy for log files. I am not saying
transmission is using a seperate log file by default. I am saying that
it has /var/log/transmission-daemon defined as a default log file
location. But the daemon arguments in the init script do not include the
option to create a log file.
> 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).
ok i will test that.
> 4. The transmission-daemon lock and pid file are created by the
init
> script and not by transmission-daemon.
>
Yeah, that is correct.
So why did your policy allow transmission to manage content in /var/run?
> 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.
F13 is fine. Just make sure you use an unmodified fedora
transmission-daemon package (no customized specs or other customizations
please)
> Raw AVC
> denials are preffered.
>
That is a given! Many thanks for reviewing this.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org/
iEYEARECAAYFAk26un4ACgkQMlxVo39jgT8qnQCeOs2vG7KuIk7LvLZHzAKO3GbC
bV4AoK63aynQsFLS4SdX6tlJwdBGz7Eu
=quaS
-----END PGP SIGNATURE-----