Set of pending changes from Gentoo
cover Set of pending changes from Gentoo
This set contains changes on various modules within the contrib/ module. It contains a few updated patches from previous submits, including the at support, now more documented (and tested).
Sven Vermeulen (9):
Fix typo in tunable declaration for fcron_crond Introducing cron_manage_log_files interface
Introduce dontaudit interfaces for leaked fd and unix stream sockets Dontaudit attempts by system_mail_t to use leaked fd or stream
sockets
Support at service
Additional postfix admin requirements
Reintroduce postfix_var_run_t for pid directory and fowner capability Postfix deferred queue should not mark mails as
postfix_spool_maildrop_t
Running qemu with SDL support requires more xserver-related
privileges
cron.fc | 1 + cron.if | 24 ++++++++++++++++++++++++ cron.te | 12 ++++++++++-- fail2ban.if | 38 ++++++++++++++++++++++++++++++++++++++ mta.te | 1 + postfix.fc | 4 ++-- postfix.if | 3 +++ postfix.te | 8 ++++++-- qemu.te | 4 ++++ 9 files changed, 89 insertions(+), 6 deletions(-)
Signature · 1 line
1.7.8.6
PATCH 1/9 Fix typo in tunable declaration for fcron_crond
--- cron.te | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
cron.te +1 -1
@@ -30,7 +30,7 @@ gen_tunable(cron_userdomain_transition, false) ## <desc> ## <p> ## Determine whether extra rules -## should beenabled to support fcron. +## should be enabled to support fcron. ## </p> ## </desc> gen_tunable(fcron_crond, false)
Signature · 1 line
1.7.8.6
PATCH 1/9 Fix typo in tunable declaration for fcron_crond
Is anyone still working on fcron?
I have given up on patching it for SE Linux. Unless someone else has taken that over you won't have fcron working on a SE Linux system anyway.
Quoted 18 lines · Sven Vermeulen
Signed-off-by Sven Vermeulen <[email protected]>--- cron.te | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)cron.te +1
-1@@ -30,7 +30,7 @@ gen_tunable(cron_userdomain_transition, false) ## <desc> ## <p> ## Determine whether extra rules -## should beenabled to support fcron. +## should be enabled to support fcron. ## </p> ## </desc> gen_tunable(fcron_crond, false)
Signature · 2 lines
My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
PATCH 2/9 Introducing cron_manage_log_files interface
In reply to Sven VermeulenThe metalog system logger also tackles rotation and clean-up of log files it manages. Hence, it requires manage privileges on these log files. Cron log files are an example of this, so we introduce the cron_manage_log_files interface.
Added a logging_search_logs() call as per Dominick's suggestion.
--- cron.if | 21 +++++++++++++++++++++ 1 files changed, 21 insertions(+), 0 deletions(-)
cron.if +21 -0
@@ -463,6 +463,27 @@ interface(`cron_write_log_files',` ######################################## ## <summary> +## Create, read, write and delete +## cron log files. +## </summary> +## <param name="domain"> +## <summary> +## Domain allowed access. +## </summary> +## </param> +# +interface(`cron_manage_log_files',` + gen_require(` + type cron_log_t; + ') + + manage_files_pattern($1, cron_log_t, cron_log_t) + + logging_search_logs($1) +') + +######################################## +## <summary> ## Create specified objects in generic ## log directories with the cron log file type. ## </summary>
Signature · 1 line
1.7.8.6
PATCH 3/9 Introduce dontaudit interfaces for leaked fd and unix stream sockets
In reply to Sven VermeulenThe fail2ban application leaks file descriptors and unix stream sockets when it invokes sendmail, so introduce the necessary dontaudit interfaces which will be used in a later patch against the mta and postfix policies.
--- fail2ban.if | 38 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 38 insertions(+), 0 deletions(-)
fail2ban.if +38 -0
@@ -107,6 +107,44 @@ interface(`fail2ban_rw_inherited_tmp_files',` ######################################## ## <summary> +## Do not audit attempts to use +## fail2ban file descriptors. +## </summary> +## <param name="domain"> +## <summary> +## Domain to not audit. +## </summary> +## </param> +# +interface(`fail2ban_dontaudit_use_fds',` + gen_require(` + type fail2ban_t; + ') + + dontaudit $1 fail2ban_t:fd use; +') + +######################################## +## <summary> +## Do not audit read and write +## fail2ban unix stream sockets +## </summary> +## <param name="domain"> +## <summary> +## Domain to not audit. +## </summary> +## </param> +# +interface(`fail2ban_dontaudit_rw_stream_sockets',` + gen_require(` + type fail2ban_t; + ') + + dontaudit $1 fail2ban_t:unix_stream_socket { read write }; +') + +######################################## +## <summary> ## Read and write fail2ban unix ## stream sockets. ## </summary>
Signature · 1 line
1.7.8.6
PATCH 4/9 Dontaudit attempts by system_mail_t to use leaked fd or stream sockets
In reply to Sven VermeulenWhen fail2ban invokes sendmail to send out a mail event, denials such as the following ones occur, but without any consequence on the functioning itself (the mails are sent out correctly, no errors in logs):
type=AVC msg=audit(1352348532.580:1313): avc: denied { read write } for pid=28042 comm="sendmail" path="socket:[1480]" dev="sockfs" ino=1480 scontext=system_u:system_r:system_mail_t tcontext=system_u:system_r:fail2ban_t tclass=unix_stream_socket
type=AVC msg=audit(1352348532.590:1314): avc: denied { use } for pid=28047 comm="postdrop" path="/dev/null" dev="devtmpfs" ino=3075 scontext=system_u:system_r:postfix_postdrop_t tcontext=system_u:system_r:fail2ban_t tclass=fd
It looks like these are due to leaked file descriptors.
--- mta.te | 1 + postfix.te | 4 ++++ 2 files changed, 5 insertions(+), 0 deletions(-)
mta.te +1 -0
@@ -249,6 +249,7 @@ optional_policy(` ') optional_policy(` + fail2ban_dontaudit_rw_stream_sockets(system_mail_t) fail2ban_append_log(system_mail_t) fail2ban_rw_inherited_tmp_files(system_mail_t) ')
postfix.te +4 -0
@@ -604,6 +604,10 @@ optional_policy(` ') optional_policy(` + fail2ban_dontaudit_use_fds(postfix_postdrop_t) +') + +optional_policy(` fstools_read_pipes(postfix_postdrop_t) ')
Signature · 1 line
1.7.8.6
PATCH 5/9 Support at service
In reply to Sven VermeulenThe at daemon allows users and system administrators to define tasks to be executed once on a particular time. The at service captures the current session's environment and stores it as part of the task to be executed.
When ran, at "locks" the job (in the /var/spool/at/atjobs location) and executes it, capturing its output in the /var/spool/at/atspool location.
Because of this log output capturing, it doesn't make sense to keep the atspool location as user_cron_spool_t as any service ran through at needs to be able to write to this location, and we don't want such services to have write access to the user_cron_spool_t type. Hence we introduce the user_cron_spool_log_t type for the logging output, allow it to be read by the system mailer (as it is invoked to send the resulting output) and written by any service that is allowed to be called by cron (through cron_system_entry).
The cron daemon requires manage privileges on the /var/spool/at/atjobs location (labeled user_cron_spool_t) as it uses locking techniques on the at job scripts themselves (lock files) and removes the scripts once executed.
The capability for the admin_crontab_t only seems to be needed for the admin_crontab_t domain, using the regular crontab_t domain for users does not exhibit this behavior.
--- cron.fc | 1 + cron.if | 3 +++ cron.te | 10 +++++++++- 3 files changed, 13 insertions(+), 1 deletions(-)
cron.fc +1 -0
@@ -27,6 +27,7 @@ /var/spool/anacron(/.*)? gen_context(system_u:object_r:system_cron_spool_t,s0) /var/spool/at(/.*)? gen_context(system_u:object_r:user_cron_spool_t,s0) +/var/spool/at/atspool(/.*)? gen_context(system_u:object_r:user_cron_spool_log_t,s0) /var/spool/cron -d gen_context(system_u:object_r:cron_spool_t,s0) #/var/spool/cron/root -- gen_context(system_u:object_r:sysadm_cron_spool_t,s0)
cron.if +3 -0
@@ -307,8 +307,11 @@ interface(`cron_admin_role',` interface(`cron_system_entry',` gen_require(` type crond_t, system_cronjob_t; + type user_cron_spool_log_t; ') + rw_files_pattern($1, user_cron_spool_log_t, user_cron_spool_log_t) + domtrans_pattern(system_cronjob_t, $2, $1) domtrans_pattern(crond_t, $2, $1)
cron.te +9 -1
@@ -121,6 +121,11 @@ files_type(user_cron_spool_t) ubac_constrained(user_cron_spool_t) mta_system_content(user_cron_spool_t) +type user_cron_spool_log_t; +logging_log_file(user_cron_spool_log_t) +ubac_constrained(user_cron_spool_log_t) +mta_system_content(user_cron_spool_log_t) + ifdef(`enable_mcs',` init_ranged_daemon_domain(crond_t, crond_exec_t, s0 - mcs_systemhigh) ')
@@ -188,6 +193,7 @@ tunable_policy(`fcron_crond',` # Admin local policy # +allow admin_crontab_t self:capability fsetid; allow admin_crontab_t crond_t:process signal; selinux_get_fs_mount(admin_crontab_t)
@@ -237,9 +243,11 @@ list_dirs_pattern(crond_t, system_cron_spool_t, system_cron_spool_t) read_files_pattern(crond_t, system_cron_spool_t, system_cron_spool_t) rw_dirs_pattern(crond_t, user_cron_spool_t, user_cron_spool_t) -read_files_pattern(crond_t, user_cron_spool_t, user_cron_spool_t) +manage_files_pattern(crond_t, user_cron_spool_t, user_cron_spool_t) manage_lnk_files_pattern(crond_t, user_cron_spool_t, user_cron_spool_t) +manage_files_pattern(crond_t, user_cron_spool_log_t, user_cron_spool_log_t) + allow crond_t system_cronjob_t:process transition; allow crond_t system_cronjob_t:fd use; allow crond_t system_cronjob_t:key manage_key_perms;
Signature · 1 line
1.7.8.6
PATCH 6/9 Additional postfix admin requirements
In reply to Sven VermeulenWhen administering postfix, the admin also needs to be able to run master (without transitioning - for instance for configuration file integrity validation), postqueue (for handling the queues) as well as have stream-connect rights towards the master (for the postfix clients that interact with a running master daemon through a socket).
Adding those inside postfix_admin().
--- postfix.if | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
postfix.if +3 -0
@@ -739,5 +739,8 @@ interface(`postfix_admin',` files_search_tmp($1) admin_pattern($1, { postfix_server_tmp_content postfix_map_tmp_t }) + postfix_exec_master($1) + postfix_exec_postqueue($1) + postfix_stream_connect_master($1) postfix_run_map($1, $2) ')
Signature · 1 line
1.7.8.6
PATCH 7/9 Reintroduce postfix_var_run_t for pid directory and fowner capability
In reply to Sven VermeulenIn August 21, a few changes were made to the postfix module that were reverted somewhere in the last few months. Reintroducing these changes:
- Add in the fowner capability for the master domain, needed for running chown on the queue's.
- Mark the pid directory as a pid directory
See http://oss.tresys.com/pipermail/refpolicy/2012-August/005475.html for more information.
--- postfix.fc | 2 +- postfix.te | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
postfix.fc +1 -1
@@ -50,7 +50,7 @@ /var/spool/postfix/deferred(/.*)? gen_context(system_u:object_r:postfix_spool_maildrop_t,s0) /var/spool/postfix/defer(/.*)? gen_context(system_u:object_r:postfix_spool_maildrop_t,s0) /var/spool/postfix/maildrop(/.*)? gen_context(system_u:object_r:postfix_spool_maildrop_t,s0) -/var/spool/postfix/pid/.* gen_context(system_u:object_r:postfix_var_run_t,s0) +/var/spool/postfix/pid(/.*)? gen_context(system_u:object_r:postfix_var_run_t,s0) /var/spool/postfix/private(/.*)? gen_context(system_u:object_r:postfix_private_t,s0) /var/spool/postfix/public(/.*)? gen_context(system_u:object_r:postfix_public_t,s0) /var/spool/postfix/bounce(/.*)? gen_context(system_u:object_r:postfix_spool_bounce_t,s0)
postfix.te +2 -2
@@ -123,7 +123,7 @@ allow postfix_domain postfix_master_t:process sigchld; allow postfix_domain postfix_spool_t:dir list_dir_perms; -allow postfix_domain postfix_var_run_t:file manage_file_perms; +manage_files_pattern(postfix_domain, postfix_var_run_t, postfix_var_run_t) files_pid_filetrans(postfix_domain, postfix_var_run_t, file) kernel_read_system_state(postfix_domain)
@@ -194,7 +194,7 @@ domain_use_interactive_fds(postfix_user_domains) # Master local policy # -allow postfix_master_t self:capability { chown dac_override kill setgid setuid net_bind_service sys_tty_config }; +allow postfix_master_t self:capability { chown dac_override kill fowner setgid setuid net_bind_service sys_tty_config }; allow postfix_master_t self:capability2 block_suspend; allow postfix_master_t self:process setrlimit; allow postfix_master_t self:tcp_socket create_stream_socket_perms;
Signature · 1 line
1.7.8.6
PATCH 8/9 Postfix deferred queue should not mark mails as postfix_spool_maildrop_t
In reply to Sven VermeulenPostfix /moves/ the mail files between the queues as they are processed. Mails that cannot be delivered currently are pushed towards the deferred queue. However, when this occurs, the mail file retains its context (as it is moved, not copied) for postfix_spool_t.
If we would relabel the system or directory at that point, the mail gets labeled postfix_spool_maildrop_t. When a new attempt is made to deliver, the postfix daemons, like local, are not able to read (and process) the mail anymore since they do not hold read rights on the postfix_spool_maildrop_t type.
Only mark the deferred directory as postfix_spool_maildrop_t solves this.
--- postfix.fc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
postfix.fc +1 -1
@@ -47,7 +47,7 @@ /var/lib/postfix.* gen_context(system_u:object_r:postfix_data_t,s0) /var/spool/postfix.* gen_context(system_u:object_r:postfix_spool_t,s0) -/var/spool/postfix/deferred(/.*)? gen_context(system_u:object_r:postfix_spool_maildrop_t,s0) +/var/spool/postfix/deferred(/.*)? -d gen_context(system_u:object_r:postfix_spool_maildrop_t,s0) /var/spool/postfix/defer(/.*)? gen_context(system_u:object_r:postfix_spool_maildrop_t,s0) /var/spool/postfix/maildrop(/.*)? gen_context(system_u:object_r:postfix_spool_maildrop_t,s0) /var/spool/postfix/pid(/.*)? gen_context(system_u:object_r:postfix_var_run_t,s0)
Signature · 1 line
1.7.8.6
PATCH 8/9 Postfix deferred queue should not mark mails as postfix_spool_maildrop_t
Quoted 22 lines · Sven Vermeulen
Postfix /moves/ the mail files between the queues as they are processed. Mails that cannot be delivered currently are pushed towards the deferred queue. However, when this occurs, the mail file retains its context (as it is moved, not copied) for
postfix_spool_t.If we would relabel the system or directory at that point, the mail gets labeled
postfix_spool_maildrop_t. When a new attempt is made to deliver, the postfix daemons, like local, are not able to read (and process) the mail anymore since they do not hold read rights on thepostfix_spool_maildrop_ttype.Only mark the deferred directory as
postfix_spool_maildrop_tsolves this.Signed-off-by Sven Vermeulen <[email protected]>--- postfix.fc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)postfix.fc +0
-0
postfix.fc line 53
Quoted 8 lines
postfix.fc +1
-1@@ -47,7 +47,7 @@ /var/lib/postfix.* gen_context(system_u:object_r:postfix_data_t,s0) /var/spool/postfix.* gen_context(system_u:object_r:postfix_spool_t,s0) -/var/spool/postfix/deferred(/.*)? gen_context(system_u:object_r:postfix_spool_maildrop_t,s0) +/var/spool/postfix/deferred(/.*)? -d gen_context(system_u:object_r:postfix_spool_maildrop_t,s0) /var/spool/postfix/defer(/.*)? gen_context(system_u:object_r:postfix_spool_maildrop_t,s0) /var/spool/postfix/maildrop(/.*)? gen_context(system_u:object_r:postfix_spool_maildrop_t,s0) /var/spool/postfix/pid(/.*)? gen_context(system_u:object_r:postfix_var_run_t,s0)
"Only mark the deferred directory as postfix_spool_maildrop_t solves this."
The file context spec does not apply to just the deferred dir but also applies to all dirs below, just so that you are aware of that
PATCH 9/9 Running qemu with SDL support requires more xserver-related privileges
In reply to Sven VermeulenWhen trying to start qemu with SDL, the qemu application just fails with the following denial in the logs:
Nov 11 18:06:44 lain kernel: [20076.499347] type=1400
audit(1352653604.042:3987): avc: denied { read } for pid=28245 comm="qemu-system-x86" name=".Xauthority" dev="dm-0" ino=20709392 scontext=staff_u:staff_r:qemu_t tcontext=staff_u:object_r:xauth_home_t tclass=file
Although the application seems to run with just xserver_read_user_xauth(qemu_t) set, it does still provide denials like the following:
Nov 14 20:58:51 lain kernel: [39885.690744] type=1400 audit(1352923131.430:154):
avc: denied { unix_read unix_write } for pid=1973 comm="X" key=0 scontext=staff_u:staff_r:xserver_t tcontext=staff_u:staff_r:qemu_t tclass=shm
As qemu is acting as an X11 application (when build with SDL support), it makes sense to use xserver_user_x_domain_template.
--- qemu.te | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
qemu.te +4 -0
@@ -37,6 +37,10 @@ tunable_policy(`qemu_full_network',` corenet_tcp_connect_all_ports(qemu_t) ') +optional_policy(` + xserver_user_x_domain_template(qemu, qemu_t, qemu_tmpfs_t) +') + ######################################## # # Unconfined local policy
Signature · 1 line
1.7.8.6
cover Set of pending changes from Gentoo
In reply to Sven VermeulenQuoted 18 lines · Sven Vermeulen
This set contains changes on various modules within the contrib/ module. It contains a few updated patches from previous submits, including the at support, now more documented (and tested).
Sven Vermeulen (9):
Fix typo in tunable declaration forfcron_crondIntroducingcron_manage_log_filesinterface
Introduce dontaudit interfaces for leaked fd and unix stream sockets Dontaudit attempts bysystem_mail_tto use leaked fd or stream
sockets
Support at service
Additional postfix admin requirements
Reintroducepostfix_var_run_tfor pid directory and fowner capability Postfix deferred queue should not mark mails as
postfix_spool_maildrop_t
Running qemu with SDL support requires more xserver-related
privileges
Quoted 11 lines
cron.fc | 1 + cron.if | 24 ++++++++++++++++++++++++ cron.te | 12 ++++++++++-- fail2ban.if | 38 ++++++++++++++++++++++++++++++++++++++ mta.te | 1 + postfix.fc | 4 ++-- postfix.if | 3 +++ postfix.te | 8 ++++++-- qemu.te | 4 ++++ 9 files changed, 89 insertions(+), 6 deletions(-)
This patch set was merged, Thanks