-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/29/2011 12:06 AM, Mr Dash Four wrote:
See attached. I have enclosed 2 policy modules to start with and see how it goes. I also enclosed a readme file with some notes on these policies. Comments, suggestions are mostly welcome!
Hi,
I took a look at your policy modules. I would like to focus on the transmission-daemon policy module.
I am not confident that any skype policy has a good chance of getting adopted or any other gui user app for that matter.
The user space is not confined in a way yet to support gui user application policy optimal, and until it is i do not want to waste time on getting any gui user application policy accepted.
Confining transmission-daemon on the other hand seems like a good idea.
I have perused your policy and i rewrote it partly.
However i have only tested starting and stopping transmission-daemon.
I have not actually used it and so policy is missing.
Could you please test my policy and provide feedback to that it can be extended?
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?
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.
2. Add to init.te:
optional_policy(` bittorrent_read_daemon_config_files(initrc_t) ')
3. The bittorrent policy module:
- -- 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)
type bittorrentd_initrc_exec_t; init_script_file(bittorrentd_initrc_exec_t)
type bittorrentd_etc_t; files_config_file(bittorrentd_etc_t)
type bittorrentd_var_lib_t; files_type(bittorrentd_var_lib_t)
type bittorrentd_var_log_t; logging_log_file(bittorrentd_var_log_t)
######################################## # # Local policy #
allow bittorrentd_t self:capability { setgid setuid }; dontaudit bittorrentd_t self:capability sys_tty_config; allow bittorrentd_t self:process { getsched setsched }; allow bittorrentd_t self:fifo_file rw_fifo_file_perms; allow bittorrentd_t self:tcp_socket { accept listen }; allow bittorrentd_t self:unix_stream_socket create_socket_perms;
manage_dirs_pattern(bittorrentd_t, bittorrentd_var_lib_t, bittorrentd_var_lib_t) manage_files_pattern(bittorrentd_t, bittorrentd_var_lib_t, bittorrentd_var_lib_t)
allow bittorrentd_t bittorrentd_var_log_t:file { create_file_perms setattr_file_perms append_file_perms }; logging_log_filetrans(bittorrentd_t, bittorrentd_var_log_t, file)
kernel_read_network_state(bittorrentd_t)
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)
corenet_tcp_bind_bittorrent_ctl_port(bittorrentd_t) corenet_tcp_sendrecv_bittorrent_ctl_port(bittorrentd_t) corenet_sendrecv_bittorrent_ctl_server_packets(bittorrentd_t)
dev_read_urand(bittorrentd_t)
domain_use_interactive_fds(bittorrentd_t)
files_search_var_lib(bittorrentd_t) files_search_pids(bittorrentd_t)
fs_search_auto_mountpoints(bittorrentd_t)
auth_use_nsswitch(bittorrentd_t)
logging_send_syslog_msg(bittorrentd_t)
miscfiles_read_localization(bittorrentd_t) miscfiles_read_public_files(bittorrentd_t)
tunable_policy(`allow_bittorrentd_use_cifs',` fs_read_cifs_files(bittorrentd_t) ')
tunable_policy(`allow_bittorrentd_use_nfs',` fs_read_nfs_files(bittorrentd_t) ')
optional_policy(` seutil_sigchld_newrole(bittorrentd_t) ')
- -- 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; ')
- -- c: bittorrent.fc:
/etc/rc.d/init.d/transmission-daemon -- gen_context(system_u:object_r:bittorrentd_initrc_exec_t,s0)
/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)
/var/lib/transmission(/.*)? gen_context(system_u:object_r:bittorrentd_var_lib_t,s0)
/var/log/transmission-daemon.log.* -- gen_context(system_u:object_r:bittorrentd_var_log_t,s0)
Please compare what i have to what you have and ask questions about why my implementation differs from yours.
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.
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)
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.
I only started and stopped the server, and it did not create any log files.
4. The transmission-daemon lock and pid file are created by the init script and not by transmission-daemon.
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.
Please try out my version of the policy on a clean and unmodified Fedora 14+ transmission-daemon installation, and provide feedback. Raw AVC denials are preffered.
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:
- 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:
- 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).
- 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.
- 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).
- The transmission-daemon lock and pid file are created by the init
script and not by transmission-daemon.
Yeah, that is correct.
- 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.
-----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:
- 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:
- 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.
- 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.)
- 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.
- 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?
- 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 SIGNED MESSAGE----- Hash: SHA1
On 04/29/2011 03:17 PM, Dominick Grift wrote:
I see you have removed the NAT-PMP/uPNP tunable. Any reason for that?
No i just did not encounter it. If you can (re) produce it then i will be glad to add it.
selinux@lists.fedoraproject.org