new policy modules submission

[Dominick Grift]

-----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-----