[refpolicy] [PATCH 0/5] Small batch of updates for contrib

[refpolicy] [PATCH 0/5] Small batch of updates for contrib

[Sven Vermeulen]

This patchset has a few updates on the contrib-located modules. 

Sven Vermeulen (5):
  Introducing cron_manage_log_files interface
  Portage fetch domain needs to access certificates
  Introduce dontaudits for leaked fd and unix stream sockets
  Dontaudit attempts by system_mail_t to use leaked fd or stream
    sockets
  Support at service

 cron.fc     |    1 +
 cron.if     |   23 +++++++++++++++++++++++
 cron.te     |   10 +++++++++-
 fail2ban.if |   38 ++++++++++++++++++++++++++++++++++++++
 mta.te      |    2 ++
 portage.te  |    1 +
 6 files changed, 74 insertions(+), 1 deletions(-)

-- 
1.7.8.6

[refpolicy] [PATCH 1/5] Introducing cron_manage_log_files interface

[Sven Vermeulen]

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

See also https://bugs.gentoo.org/show_bug.cgi?id=440128

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 cron.if |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/cron.if b/cron.if
index a1ecb7f..760180c 100644
--- a/cron.if
+++ b/cron.if
@@ -463,6 +463,26 @@ 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)
+')
+
+
+########################################
+## <summary>
 ##	Create specified objects in generic
 ##	log directories with the cron log file type.
 ## </summary>
-- 
1.7.8.6

[refpolicy] [PATCH 1/5] Introducing cron_manage_log_files interface

[Dominick Grift]

On Sat, 2012-11-10 at 17:50 +0100, Sven Vermeulen wrote:
> The 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.
> 
> See also https://bugs.gentoo.org/show_bug.cgi?id=440128
> 
> Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> ---
>  cron.if |   20 ++++++++++++++++++++
>  1 files changed, 20 insertions(+), 0 deletions(-)
> 
> diff --git a/cron.if b/cron.if
> index a1ecb7f..760180c 100644
> --- a/cron.if
> +++ b/cron.if
> @@ -463,6 +463,26 @@ 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;
> +	')
> +

Needs a logging_search_logs($1) in my view

> +	manage_files_pattern($1, cron_log_t, cron_log_t)
> +')
> +
> +
> +########################################
> +## <summary>
>  ##	Create specified objects in generic
>  ##	log directories with the cron log file type.
>  ## </summary>

[refpolicy] [PATCH 2/5] Portage fetch domain needs to access certificates

[Sven Vermeulen]

When source code is available through a secured connection location (HTTPS),
portage invokes wget in the portage_fetch_t domain, but needs to access the
certificates on the system to verify the validity of the remotely presented
certificate.

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 portage.te |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/portage.te b/portage.te
index 1425e30..78ab51e 100644
--- a/portage.te
+++ b/portage.te
@@ -309,6 +309,7 @@ term_search_ptys(portage_fetch_t)
 
 auth_use_nsswitch(portage_fetch_t)
 
+miscfiles_read_generic_certs(portage_fetch_t)
 miscfiles_read_localization(portage_fetch_t)
 
 userdom_use_user_terminals(portage_fetch_t)
-- 
1.7.8.6

[refpolicy] [PATCH 2/5] Portage fetch domain needs to access certificates

[Dominick Grift]

On Sat, 2012-11-10 at 17:50 +0100, Sven Vermeulen wrote:
> When source code is available through a secured connection location (HTTPS),
> portage invokes wget in the portage_fetch_t domain, but needs to access the
> certificates on the system to verify the validity of the remotely presented
> certificate.
> 
> Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> ---
>  portage.te |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/portage.te b/portage.te
> index 1425e30..78ab51e 100644
> --- a/portage.te
> +++ b/portage.te
> @@ -309,6 +309,7 @@ term_search_ptys(portage_fetch_t)
>  
>  auth_use_nsswitch(portage_fetch_t)
>  
> +miscfiles_read_generic_certs(portage_fetch_t)
>  miscfiles_read_localization(portage_fetch_t)
>  
>  userdom_use_user_terminals(portage_fetch_t)

This is merged, thanks

[refpolicy] [PATCH 3/5] Introduce dontaudits for leaked fd and unix stream sockets

[Sven Vermeulen]

The 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 policy.

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 fail2ban.if |   38 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/fail2ban.if b/fail2ban.if
index 733a689..9fbba62 100644
--- a/fail2ban.if
+++ b/fail2ban.if
@@ -68,6 +68,25 @@ interface(`fail2ban_run_client',`
 
 #####################################
 ## <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>
 ##	Connect to fail2ban over a
 ##	unix domain stream socket.
 ## </summary>
@@ -107,6 +126,25 @@ interface(`fail2ban_rw_inherited_tmp_files',`
 
 ########################################
 ## <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 rw_stream_socket_perms;
+')
+
+########################################
+## <summary>
 ##	Read and write fail2ban unix
 ##	stream sockets.
 ## </summary>
-- 
1.7.8.6

[refpolicy] [PATCH 3/5] Introduce dontaudits for leaked fd and unix stream sockets

[Dominick Grift]

On Sat, 2012-11-10 at 17:50 +0100, Sven Vermeulen wrote:
> The 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 policy.
> 
> Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> ---
>  fail2ban.if |   38 ++++++++++++++++++++++++++++++++++++++
>  1 files changed, 38 insertions(+), 0 deletions(-)
> 
> diff --git a/fail2ban.if b/fail2ban.if
> index 733a689..9fbba62 100644
> --- a/fail2ban.if
> +++ b/fail2ban.if
> @@ -68,6 +68,25 @@ interface(`fail2ban_run_client',`
>  
>  #####################################
>  ## <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>
>  ##	Connect to fail2ban over a
>  ##	unix domain stream socket.
>  ## </summary>
> @@ -107,6 +126,25 @@ interface(`fail2ban_rw_inherited_tmp_files',`
>  
>  ########################################
>  ## <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 rw_stream_socket_perms;
> +')

We should read create a rw_inherited_socket_perms permission set and use
that instead in my honest opinion

> +########################################
> +## <summary>
>  ##	Read and write fail2ban unix
>  ##	stream sockets.
>  ## </summary>

[refpolicy] [PATCH 3/5] Introduce dontaudits for leaked fd and unix stream sockets

[Sven Vermeulen]

On Wed, Nov 14, 2012 at 07:06:13PM +0100, Dominick Grift wrote:
> > +interface(`fail2ban_dontaudit_rw_stream_sockets',`
> > +	gen_require(`
> > +		type fail2ban_t;
> > +	')
> > +
> > +	dontaudit $1 fail2ban_t:unix_stream_socket rw_stream_socket_perms;
> > +')
> 
> We should read create a rw_inherited_socket_perms permission set and use
> that instead in my honest opinion

Would a more generic "rw_inherited_perms" be sufficient (i.e. without
referring to the class)? As far as I know, inherited file descriptors or
sockets (or ...) are usually just { read write };

Wkr,
	Sven Vermeulen

[refpolicy] [PATCH 3/5] Introduce dontaudits for leaked fd and unix stream sockets

[Dominick Grift]

On Wed, 2012-11-14 at 20:20 +0100, Sven Vermeulen wrote:
> On Wed, Nov 14, 2012 at 07:06:13PM +0100, Dominick Grift wrote:
> > > +interface(`fail2ban_dontaudit_rw_stream_sockets',`
> > > +	gen_require(`
> > > +		type fail2ban_t;
> > > +	')
> > > +
> > > +	dontaudit $1 fail2ban_t:unix_stream_socket rw_stream_socket_perms;
> > > +')
> > 
> > We should read create a rw_inherited_socket_perms permission set and use
> > that instead in my honest opinion
> 
> Would a more generic "rw_inherited_perms" be sufficient (i.e. without
> referring to the class)? As far as I know, inherited file descriptors or
> sockets (or ...) are usually just { read write };

I do not agree. Many kinds of objects can be inherited (think files,
blk_files etc), And its often not just { read write };

I personally am interesting in just a inherited equivalent of any rw
permission set that is the same except that it lacks the open permission
(much like fedora does it)

But that is just my opinion

Inheritance gets more and more important and i think its important that
we properly support that (if some domain needs to rw some inherited
object then we should not allow/dontaudit open

Here is one example: 

https://bugzilla.redhat.com/show_bug.cgi?id=856216

in that casde it seems to only need { read write } but i have also seen
cases where it needs ioctl and so i rather allow a bit more but not open
than create a permission set with only { read write } because that
wouldnt be enough in some cases

So my suggestion (just a example)


> define(`rw_inherited_sock_file_perms',`{ getattr read write append }')
> define(`rw_sock_file_perms',`{ open rw_inherited_sock_file_perms }')


> define(`rw_inherited_fifo_file_perms',`{ getattr read write append ioctl lock }')
> define(`rw_fifo_file_perms',`{ open rw_inherited_fifo_file_perms }')

Oh and actually , seems this does not apply here anyways as sockets arent opened in the first place:


> define(`rw_socket_perms', `{ ioctl read getattr lock write setattr append bind connect getopt setopt shutdown }')

So.. i would in this case not use a permission set at all

just use the raw { read write } , example:


########################################
## <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 };
')


> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] [PATCH 3/5] Introduce dontaudits for leaked fd and unix stream sockets

[Sven Vermeulen]

On Wed, Nov 14, 2012 at 08:37:31PM +0100, Dominick Grift wrote:
> > Would a more generic "rw_inherited_perms" be sufficient (i.e. without
> > referring to the class)? As far as I know, inherited file descriptors or
> > sockets (or ...) are usually just { read write };
> 
> I do not agree. Many kinds of objects can be inherited (think files,
> blk_files etc), And its often not just { read write };

Ok, my bad, didn't know that.

> I personally am interesting in just a inherited equivalent of any rw
> permission set that is the same except that it lacks the open permission
> (much like fedora does it)

Perhaps we should just use things like:

dontaudit $1 bar_t:file { rw_file_perms ~open } 

if we want to have the same equivalent without open? 

Wkr,
	Sven Vermeulen

[refpolicy] [PATCH 3/5] Introduce dontaudits for leaked fd and unix stream sockets

[Dominick Grift]

On Wed, 2012-11-14 at 21:18 +0100, Sven Vermeulen wrote:
> On Wed, Nov 14, 2012 at 08:37:31PM +0100, Dominick Grift wrote:
> > > Would a more generic "rw_inherited_perms" be sufficient (i.e. without
> > > referring to the class)? As far as I know, inherited file descriptors or
> > > sockets (or ...) are usually just { read write };
> > 
> > I do not agree. Many kinds of objects can be inherited (think files,
> > blk_files etc), And its often not just { read write };
> 
> Ok, my bad, didn't know that.
> 
> > I personally am interesting in just a inherited equivalent of any rw
> > permission set that is the same except that it lacks the open permission
> > (much like fedora does it)
> 
> Perhaps we should just use things like:
> 
> dontaudit $1 bar_t:file { rw_file_perms ~open } 
> 
> if we want to have the same equivalent without open? 

Not sure if that particular implementation is as efficient as can be but
the result is exactly what i am interested in personally

> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] [PATCH 4/5] Dontaudit attempts by system_mail_t to use leaked fd or stream sockets

[Sven Vermeulen]

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

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 mta.te |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/mta.te b/mta.te
index 712dbf5..11e7363 100644
--- a/mta.te
+++ b/mta.te
@@ -250,6 +250,8 @@ optional_policy(`
 
 optional_policy(`
 	fail2ban_append_log(system_mail_t)
+	fail2ban_dontaudit_use_fds(system_mail_t)
+	fail2ban_dontaudit_rw_stream_sockets(system_mail_t)
 	fail2ban_rw_inherited_tmp_files(system_mail_t)
 ')
 
-- 
1.7.8.6

[refpolicy] [PATCH 4/5] Dontaudit attempts by system_mail_t to use leaked fd or stream sockets

[Dominick Grift]

On Sat, 2012-11-10 at 17:50 +0100, Sven Vermeulen wrote:
> When 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.
> 
> Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
> ---
>  mta.te |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/mta.te b/mta.te
> index 712dbf5..11e7363 100644
> --- a/mta.te
> +++ b/mta.te
> @@ -250,6 +250,8 @@ optional_policy(`
>  
>  optional_policy(`
>  	fail2ban_append_log(system_mail_t)
> +	fail2ban_dontaudit_use_fds(system_mail_t)

The fd use; is for postfix_postdrop_t and not system_mail_t as per above
avc denials

> +	fail2ban_dontaudit_rw_stream_sockets(system_mail_t)
>  	fail2ban_rw_inherited_tmp_files(system_mail_t)
>  ')
>  

[refpolicy] [PATCH 5/5] Support at service

[Sven Vermeulen]

The 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).

Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
 cron.fc |    1 +
 cron.if |    3 +++
 cron.te |   10 +++++++++-
 3 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/cron.fc b/cron.fc
index c542ac1..a7bfe6d 100644
--- a/cron.fc
+++ b/cron.fc
@@ -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)
diff --git a/cron.if b/cron.if
index 760180c..99c9503 100644
--- a/cron.if
+++ b/cron.if
@@ -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)
 
diff --git a/cron.te b/cron.te
index fb3adc6..3a3d0f6 100644
--- a/cron.te
+++ b/cron.te
@@ -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;
-- 
1.7.8.6

[refpolicy] [PATCH 5/5] Support at service

[Dominick Grift]

On Sat, 2012-11-10 at 17:50 +0100, Sven Vermeulen wrote:
> /var/spool/at/atspool(/.*)?

Something creates this location because it is not installed (at least in
fedora. yum whatprovides /var/spool/at/atspool yields no results)

My guess is that this would need at least a file type transition

[refpolicy] [PATCH 5/5] Support at service

[Sven Vermeulen]

On Wed, Nov 14, 2012 at 07:03:23PM +0100, Dominick Grift wrote:
> On Sat, 2012-11-10 at 17:50 +0100, Sven Vermeulen wrote:
> > /var/spool/at/atspool(/.*)?
> 
> Something creates this location because it is not installed (at least in
> fedora. yum whatprovides /var/spool/at/atspool yields no results)
> 
> My guess is that this would need at least a file type transition

Here, the location is created by the package manager through the "at"
package:

testsys ~ # qfile /var/spool/at/atspool/
sys-process/at (/var/spool/at/atspool)

(This is comparable as saying that the directory is created by an RPM).

Wkr,
	Sven Vermeulen

[refpolicy] [PATCH 5/5] Support at service

[Dominick Grift]

On Wed, 2012-11-14 at 20:03 +0100, Sven Vermeulen wrote:
> On Wed, Nov 14, 2012 at 07:03:23PM +0100, Dominick Grift wrote:
> > On Sat, 2012-11-10 at 17:50 +0100, Sven Vermeulen wrote:
> > > /var/spool/at/atspool(/.*)?
> > 
> > Something creates this location because it is not installed (at least in
> > fedora. yum whatprovides /var/spool/at/atspool yields no results)
> > 
> > My guess is that this would need at least a file type transition
> 
> Here, the location is created by the package manager through the "at"
> package:
> 
> testsys ~ # qfile /var/spool/at/atspool/
> sys-process/at (/var/spool/at/atspool)
> 
> (This is comparable as saying that the directory is created by an RPM).
> 

May this is gentoo specific, on my f17 system this location does not
even exist

Are you sure that it works as you expect it? 

Also the patch has stuff that seems unrelated. For example:

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

Why did you change that?

Also why does the following only apply for cron admin role and admin
crontab? Do you know why the fsetid for admin_crontab_t is needed?:

> +allow admin_crontab_t self:capability fsetid;


> +               type user_cron_spool_log_t;
>         ')
>  
> +       rw_files_pattern($1, user_cron_spool_log_t,
> user_cron_spool_log_t)
> +
> 



> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] [PATCH 5/5] Support at service

[Sven Vermeulen]

On Wed, Nov 14, 2012 at 08:18:32PM +0100, Dominick Grift wrote:
> May this is gentoo specific, on my f17 system this location does not
> even exist
> 
> Are you sure that it works as you expect it? 

It seems to yes, I'm using it often the last few days to test out job
invocation from system cron, without having to edit my crontabs over and
over gain:

echo "layman -S" | at now+1min

Easy as pie to test stuff.

> Also the patch has stuff that seems unrelated. For example:
> 
> > -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)
> 
> Why did you change that?

Well, there are two parts of the at-stuff: one is the atjobs, the other is
atspool. In atjobs (labeled user_cron_spool_t) the scripts are placed that
are to be executed. These scripts, once executed, add in lock files inside
the atjobs location (hence the manage_files_pattern for crond_t).

> Also why does the following only apply for cron admin role and admin
> crontab? Do you know why the fsetid for admin_crontab_t is needed?:
> 
> > +allow admin_crontab_t self:capability fsetid;


It might also be for non-admin cron stuff, I'm currently only testing with
admin. I believe it is needed while writing the scripts in the atjob
location.

testsys ~ # echo ls | at now+1min
warning: commands will be executed using /bin/sh
job 21 at Wed Nov 14 20:31:00 2012
testsys ~ # cat /var/log/avc.log 
Nov 14 20:30:16 testsys kernel: [ 1746.093723] type=1400
audit(1352921416.791:31): avc:  granted  { fsetid } for  pid=3573 comm="at"
capability=4  scontext=root:sysadm_r:admin_crontab_t
tcontext=root:sysadm_r:admin_crontab_t tclass=capability
Nov 14 20:30:16 testsys kernel: [ 1746.093734] type=1400
audit(1352921416.791:32): avc:  granted  { fsetid } for  pid=3573 comm="at"
capability=4  scontext=root:sysadm_r:admin_crontab_t
tcontext=root:sysadm_r:admin_crontab_t tclass=capability

Wkr,
	Sven Vermeulen

[refpolicy] [PATCH 5/5] Support at service

[Dominick Grift]

On Wed, 2012-11-14 at 20:31 +0100, Sven Vermeulen wrote:
> On Wed, Nov 14, 2012 at 08:18:32PM +0100, Dominick Grift wrote:
> > May this is gentoo specific, on my f17 system this location does not
> > even exist
> > 
> > Are you sure that it works as you expect it? 
> 
> It seems to yes, I'm using it often the last few days to test out job
> invocation from system cron, without having to edit my crontabs over and
> over gain:
> 
> echo "layman -S" | at now+1min
> 
> Easy as pie to test stuff.
> 
> > Also the patch has stuff that seems unrelated. For example:
> > 
> > > -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)
> > 
> > Why did you change that?
> 
> Well, there are two parts of the at-stuff: one is the atjobs, the other is
> atspool. In atjobs (labeled user_cron_spool_t) the scripts are placed that
> are to be executed. These scripts, once executed, add in lock files inside
> the atjobs location (hence the manage_files_pattern for crond_t).
> 
> > Also why does the following only apply for cron admin role and admin
> > crontab? Do you know why the fsetid for admin_crontab_t is needed?:
> > 
> > > +allow admin_crontab_t self:capability fsetid;
> 
> 
> It might also be for non-admin cron stuff, I'm currently only testing with
> admin. I believe it is needed while writing the scripts in the atjob
> location.
> 
> testsys ~ # echo ls | at now+1min
> warning: commands will be executed using /bin/sh
> job 21 at Wed Nov 14 20:31:00 2012
> testsys ~ # cat /var/log/avc.log 
> Nov 14 20:30:16 testsys kernel: [ 1746.093723] type=1400
> audit(1352921416.791:31): avc:  granted  { fsetid } for  pid=3573 comm="at"
> capability=4  scontext=root:sysadm_r:admin_crontab_t
> tcontext=root:sysadm_r:admin_crontab_t tclass=capability
> Nov 14 20:30:16 testsys kernel: [ 1746.093734] type=1400
> audit(1352921416.791:32): avc:  granted  { fsetid } for  pid=3573 comm="at"
> capability=4  scontext=root:sysadm_r:admin_crontab_t
> tcontext=root:sysadm_r:admin_crontab_t tclass=capability

I am not opposed to adding this but could you pretty please test it a
little more first, also for other scenarios (users other than admin)

> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy