[refpolicy] cron patches and remaining questions

[refpolicy] cron patches and remaining questions

[HarryCiao]

Hi Chris and all,
 
I've run into some cron issues and come up with the attached 3 patches, so far I am new to cron and cron.pp so it's likely there is a better way to fix the problems, any comments are greatly welcomed!
 
Aslo there are a few cron problems that have not been fixed after applying these 3 patches:
 
1. on creation of /var/log/cron.log, its label is still var_log_t, the type_transition rule still not take effect;
 
2. on creation of /var/spool/cron/root by the crontab command, its label is still cron_spool_t, the type_transition rule still not take effect;
 
3. if pam_loginuid.so is used for the session phase in crond's PAM config file, then there will be PAM related issues:
 
[root/sysadm_r/s0 at qemu-client ~]# grep pam_loginuid /etc/pam.d/crond 
session    required   pam_loginuid.so
[root/sysadm_r/s0 at qemu-client ~]# 
 
Jan 31 09:30:01 QtCao crond[818]: Cannot make/remove an entry for the specified session
Jan 31 09:30:01 QtCao crond[818]: CRON (root) ERROR: failed to open PAM security session: Unknown error 4294967292
Jan 31 09:30:01 QtCao crond[818]: CRON (root) ERROR: cannot set security context
and the related audit messages are:
time->Fri Jan 28 05:30:02 2011
type=USER_START msg=audit(1296192602.112:2919): user pid=2652 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:crond_t:s0-s15:c0.c255 msg='op=PAM:session_open acct="root" exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=failed)'
----
time->Fri Jan 28 05:30:02 2011
type=USER_END msg=audit(1296192602.124:2920): user pid=2652 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:crond_t:s0-s15:c0.c255 msg='op=PAM:session_close acct="root" exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron res=failed)'

How to debug this crond PAM issue?
 
Thanks a lot!
 
Best regards,
Harry
  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110131/b72025a6/attachment.html 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-Fix-the-label-of-cron-log-files.patch
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20110131/b72025a6/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0002-Fix-var-spool-cron-labels.patch
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20110131/b72025a6/attachment-0001.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0003-Fix-cron-job-process-domain-during-system-booting-up.patch
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20110131/b72025a6/attachment-0002.pl 

[refpolicy] cron patches and remaining questions

[Guido Trentalancia]

Hello Harry,

just a quick comment on the first two issues...

On Mon, 31/01/2011 at 11.20 +0000, HarryCiao wrote:
> Hi Chris and all,
>  
> I've run into some cron issues and come up with the attached 3
> patches, so far I am new to cron and cron.pp so it's likely there is a
> better way to fix the problems, any comments are greatly welcomed!
>  
> Aslo there are a few cron problems that have not been fixed after
> applying these 3 patches:
>  
> 1. on creation of /var/log/cron.log, its label is still var_log_t, the
> type_transition rule still not take effect;

This is consistent with the file contexts as specified by the reference
policy. What do you expect as a label for cron log files ?
 
> 2. on creation of /var/spool/cron/root by the crontab command, its
> label is still cron_spool_t, the type_transition rule still not take
> effect;

Similar considerations as above apply here (behaviour appears consistent
with current file context definitions in the reference policy). What
label do you expect for root's crontab ? Perhaps sysadm_cron_spool_t ?
It's actually commented out in the file context for the cron module.

It's very easy to change the labels, one just needs to modify the
relative cron.fc file under policy/modules/services. But what would you
change that to ? And will that be desirable for all refpolicy users ?

I have not had time to look at your patches yet, but what problem are
they supposed to tackle ? Is the problem relevant to all refpolicy
users ?

Regards,

Guido

[refpolicy] cron patches and remaining questions

[HarryCiao]

Hello Guido,
 

> Subject: Re: [refpolicy] cron patches and remaining questions
> From: guido at trentalancia.com
> To: harrytaurus2002 at hotmail.com
> CC: refpolicy at oss.tresys.com
> Date: Mon, 31 Jan 2011 22:54:10 +0100
> 
> Hello Harry,
> 
> just a quick comment on the first two issues...
> 
> On Mon, 31/01/2011 at 11.20 +0000, HarryCiao wrote:
> > Hi Chris and all,
> > 
> > I've run into some cron issues and come up with the attached 3
> > patches, so far I am new to cron and cron.pp so it's likely there is a
> > better way to fix the problems, any comments are greatly welcomed!
> > 
> > Aslo there are a few cron problems that have not been fixed after
> > applying these 3 patches:
> > 
> > 1. on creation of /var/log/cron.log, its label is still var_log_t, the
> > type_transition rule still not take effect;
> 
> This is consistent with the file contexts as specified by the reference
> policy. What do you expect as a label for cron log files ?
 
Because logging_log_filetrans interface has been called for the crond_t and system_cronjob_t:
 
cao at cao-laptop:/work/selinux/refpolicy/policy/modules$ grep logging_log_filetrans services/cron.te
logging_log_filetrans(crond_t, cron_log_t, file)
logging_log_filetrans(system_cronjob_t, cron_log_t, file)
cao at cao-laptop:/work/selinux/refpolicy/policy/modules$
 
So I expect when the crond_t creates cron log files during system booting up, this newly created file should be auto-labeled as cron_log_t, rather than the inherited label for its parent directory.
 
BTW, once we fix the label of /var/log/cron(\.log)? file, we also have to grant the write permission on it to the syslogd_t domain.

> 
> > 2. on creation of /var/spool/cron/root by the crontab command, its
> > label is still cron_spool_t, the type_transition rule still not take
> > effect;
> 
> Similar considerations as above apply here (behaviour appears consistent
> with current file context definitions in the reference policy). What
> label do you expect for root's crontab ? Perhaps sysadm_cron_spool_t ?
> It's actually commented out in the file context for the cron module.
> 
> It's very easy to change the labels, one just needs to modify the
> relative cron.fc file under policy/modules/services. But what would you
> change that to ? And will that be desirable for all refpolicy users ?
> 
> I have not had time to look at your patches yet, but what problem are
> they supposed to tackle ? Is the problem relevant to all refpolicy
> users ?
> 
 
Again, the cron_common_crontab_template has called the interface filetrans_pattern($1_t, cron_spool_t, user_cron_spool_t, file) for crontab_t and admin_crontab_t domains, so whenever root user or non-root user uses crontab command to register a new crontab files, the created /var/spool/cron/[user] files should be auto-label as user_cron_spool_t, rather than cron_spool_t, otherwise cronjob_t won't have the required entrypoint permission on it.
 
Cheers,
Harry

> Regards,
> 
> Guido
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110201/3e7c190e/attachment-0001.html 

[refpolicy] cron patches and remaining questions

[Guido Trentalancia]

Hello Harry !

On Tue, 01/02/2011 at 12.11 +0000, HarryCiao wrote:
> Hello Guido,
>  
> > Subject: Re: [refpolicy] cron patches and remaining questions
> > From: guido at trentalancia.com
> > To: harrytaurus2002 at hotmail.com
> > CC: refpolicy at oss.tresys.com
> > Date: Mon, 31 Jan 2011 22:54:10 +0100
> > 
> > Hello Harry,
> > 
> > just a quick comment on the first two issues...
> > 
> > On Mon, 31/01/2011 at 11.20 +0000, HarryCiao wrote:
> > > Hi Chris and all,
> > > 
> > > I've run into some cron issues and come up with the attached 3
> > > patches, so far I am new to cron and cron.pp so it's likely there
> is a
> > > better way to fix the problems, any comments are greatly welcomed!
> > > 
> > > Aslo there are a few cron problems that have not been fixed after
> > > applying these 3 patches:
> > > 
> > > 1. on creation of /var/log/cron.log, its label is still var_log_t,
> the
> > > type_transition rule still not take effect;
> > 
> > This is consistent with the file contexts as specified by the
> reference
> > policy. What do you expect as a label for cron log files ?
>  
> Because logging_log_filetrans interface has been called for the
> crond_t and system_cronjob_t:
>  
> cao at cao-laptop:/work/selinux/refpolicy/policy/modules$ grep
> logging_log_filetrans services/cron.te
> logging_log_filetrans(crond_t, cron_log_t, file)
> logging_log_filetrans(system_cronjob_t, cron_log_t, file)
> cao at cao-laptop:/work/selinux/refpolicy/policy/modules$
>  
> So I expect when the crond_t creates cron log files during system
> booting up, this newly created file should be auto-labeled as
> cron_log_t, rather than the inherited label for its parent directory.

No, you shouldn't expect relabeling from logging_log_filetrans(). What
is happening appears consistent with what is specified in cron.te and
cron.fc. Supposedly logging_log_filetrans() just allows creation of
files with a different label, it does not actually create them nor it
does any relabeling.

For labeling issues, you should edit cron.fc in the first place. Because
in the end, even if something is labeled differently from what is
specified there, such label won't survive a forced relabel process that
can always take place for a variety of reasons.
 
> BTW, once we fix the label of /var/log/cron(\.log)? file, we also have
> to grant the write permission on it to the syslogd_t domain.

Yes, you might have to grant different permissions if syslogd_t is going
to carry out file operations (read, open, write or whatever is
appropriate in this specific case) on a different target context.

But are you sure it's syslogd_t and not crond_t ? In general it's
crond_t that operates on the /var/log/cron(\.log)? file not syslogd_t.

So, all you might need to change is the declaration of the type being
used and the call to logging_log_file() in cron.te (after editing
cron.fc appropriately). But I haven't checked in detail...
 
> > > 2. on creation of /var/spool/cron/root by the crontab command, its
> > > label is still cron_spool_t, the type_transition rule still not
> take
> > > effect;
> > 
> > Similar considerations as above apply here (behaviour appears
> consistent
> > with current file context definitions in the reference policy). What
> > label do you expect for root's crontab ? Perhaps
> sysadm_cron_spool_t ?
> > It's actually commented out in the file context for the cron module.
> > 
> > It's very easy to change the labels, one just needs to modify the
> > relative cron.fc file under policy/modules/services. But what would
> you
> > change that to ? And will that be desirable for all refpolicy
> users ?
> > 
> > I have not had time to look at your patches yet, but what problem
> are
> > they supposed to tackle ? Is the problem relevant to all refpolicy
> > users ?
> > 
>  
> Again, the cron_common_crontab_template has called the interface
> filetrans_pattern($1_t, cron_spool_t, user_cron_spool_t, file) for
> crontab_t and admin_crontab_t domains, so whenever root user or
> non-root user uses crontab command to register a new crontab files,
> the created /var/spool/cron/[user] files should be auto-label as
> user_cron_spool_t, rather than cron_spool_t, otherwise cronjob_t won't
> have the required entrypoint permission on it.
>  
> Cheers,
> Harry
> 
> > Regards,
> > 
> > Guido
> > 
> 

[refpolicy] cron patches and remaining questions

[Guido Trentalancia]

Hello Harry !

On Tue, 01/02/2011 at 12.11 +0000, HarryCiao wrote:
> Hello Guido,
>  
> > Subject: Re: [refpolicy] cron patches and remaining questions
> > From: guido at trentalancia.com
> > To: harrytaurus2002 at hotmail.com
> > CC: refpolicy at oss.tresys.com
> > Date: Mon, 31 Jan 2011 22:54:10 +0100
> > 
> > Hello Harry,
> > 
> > just a quick comment on the first two issues...
> > 
> > On Mon, 31/01/2011 at 11.20 +0000, HarryCiao wrote:
> > > Hi Chris and all,
> > > 
> > > I've run into some cron issues and come up with the attached 3
> > > patches, so far I am new to cron and cron.pp so it's likely there
> is a
> > > better way to fix the problems, any comments are greatly welcomed!
> > > 
> > > Aslo there are a few cron problems that have not been fixed after
> > > applying these 3 patches:
> > > 
> > > 1. on creation of /var/log/cron.log, its label is still var_log_t,
> the
> > > type_transition rule still not take effect;
> > 
> > This is consistent with the file contexts as specified by the
> reference
> > policy. What do you expect as a label for cron log files ?
>  
> Because logging_log_filetrans interface has been called for the
> crond_t and system_cronjob_t:
>  
> cao at cao-laptop:/work/selinux/refpolicy/policy/modules$ grep
> logging_log_filetrans services/cron.te
> logging_log_filetrans(crond_t, cron_log_t, file)
> logging_log_filetrans(system_cronjob_t, cron_log_t, file)
> cao at cao-laptop:/work/selinux/refpolicy/policy/modules$
>  
> So I expect when the crond_t creates cron log files during system
> booting up, this newly created file should be auto-labeled as
> cron_log_t, rather than the inherited label for its parent directory.
>  
> BTW, once we fix the label of /var/log/cron(\.log)? file, we also have
> to grant the write permission on it to the syslogd_t domain.

A quick comment on the first patch
(0001-Fix-the-label-of-cron-log-files.patch).

It looks good and desirable to me, but beware that
policy/modules/system/logging.fc still bears this:

/var/log/cron[^/]*
gen_context(system_u:object_r:var_log_t,mls_systemhigh)

So you might also want to remove the latter from logging.fc and do
something else in cron.fc ?

Regards,

Guido

[refpolicy] cron patches and remaining questions

[Russell Coker]

On Tuesday 01 February 2011 23:11:30 HarryCiao wrote:
> So I expect when the crond_t creates cron log files during system booting
> up, this newly created file should be auto-labeled as cron_log_t, rather
> than the inherited label for its parent directory. 
> BTW, once we fix the label of /var/log/cron(\.log)? file, we also have to
> grant the write permission on it to the syslogd_t domain.

On which distribution does crond create /var/log/cron.log?

On Debian and Red Hat based systems it's always been created and managed by 
syslogd (or rsyslogd etc) AFAIK.

Why does anything need to change in this regard?

[refpolicy] cron patches and remaining questions

[HarryCiao]

Hi Russell,

You are right, it's my mistake, I have been sure that on my system it is the syslogd that creates cron log files so we should not commit such change, the cron log files should inherit the label from /var/log/ and that's all.

The only thing left is to remove this redundant type_transition rule from cron.te :-P

Best regards,
Harry

> From: russell at coker.com.au
> To: refpolicy at oss.tresys.com
> Subject: Re: [refpolicy] cron patches and remaining questions
> Date: Mon, 14 Feb 2011 13:12:03 +1100
> CC: harrytaurus2002 at hotmail.com; guido at trentalancia.com
> 
> On Tuesday 01 February 2011 23:11:30 HarryCiao wrote:
> > So I expect when the crond_t creates cron log files during system booting
> > up, this newly created file should be auto-labeled as cron_log_t, rather
> > than the inherited label for its parent directory. 
> > BTW, once we fix the label of /var/log/cron(\.log)? file, we also have to
> > grant the write permission on it to the syslogd_t domain.
> 
> On which distribution does crond create /var/log/cron.log?
> 
> On Debian and Red Hat based systems it's always been created and managed by 
> syslogd (or rsyslogd etc) AFAIK.
> 
> Why does anything need to change in this regard?
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110214/d5b49526/attachment.html 

[refpolicy] cron patches and remaining questions

[HarryCiao]

 

> Date: Tue, 1 Feb 2011 10:44:57 -0500
> From: cpebenito at tresys.com
> To: harrytaurus2002 at hotmail.com
> CC: refpolicy at oss.tresys.com
> Subject: Re: cron patches and remaining questions
> 
> On 01/31/11 06:20, HarryCiao wrote:
> > Hi Chris and all,
> > 
> > I've run into some cron issues and come up with the attached 3 patches,
> > so far I am new to cron and cron.pp so it's likely there is a better way
> > to fix the problems, any comments are greatly welcomed!
> > 
> > Aslo there are a few cron problems that have not been fixed after
> > applying these 3 patches:
> > 
> > 1. on creation of /var/log/cron.log, its label is still var_log_t, the
> > type_transition rule still not take effect;
> 
> I don't think cron itself is doing the logging. I think syslog is. At
> least that is how it works on my Gentoo and Rawhide machines. In light
> of this, we should look at the crond that we support (vixie cron and
> fcron are the only ones that I know of) and see if they can be
> configured to have their own log files anymore. If not, we can drop
> cron_log_t. Otherwise we should not change the logging.
> 
> In light of this, the first patch is inappropriate for now. At a
> minimum, the MLS sensitivity is wrong, since crond does not run at
> system high.
> 
> > 2. on creation of /var/spool/cron/root by the crontab command, its label
> > is still cron_spool_t, the type_transition rule still not take effect;
> 
> I'd have to do some looking into this; its not clear to me why this
> doesn't work.
> 
> Patch 2 doesn't work right because we don't want to reset the seuser
> portion of the context, as that would break UBAC systems. We could
> consider trying out some genhomedircon lines since it knows the Linux
> user names and associated seuser and we know the naming scheme of the
> cron spool files.
> 
> > 3. if pam_loginuid.so is used for the session phase in crond's PAM
> > config file, then there will be PAM related issues:
> > 
> > [root/sysadm_r/s0 at qemu-client ~]# grep pam_loginuid /etc/pam.d/crond
> > session required pam_loginuid.so
> > [root/sysadm_r/s0 at qemu-client ~]#
> > 
> > Jan 31 09:30:01 QtCao crond[818]: Cannot make/remove an entry for the
> > specified session
> > Jan 31 09:30:01 QtCao crond[818]: CRON (root) ERROR: failed to open PAM
> > security session: Unknown error 4294967292
> > Jan 31 09:30:01 QtCao crond[818]: CRON (root) ERROR: cannot set security
> > context
> > and the related audit messages are:
> > time->Fri Jan 28 05:30:02 2011
> > type=USER_START msg=audit(1296192602.112:2919): user pid=2652 uid=0
> > auid=4294967295 ses=4294967295
> > subj=system_u:system_r:crond_t:s0-s15:c0.c255 msg='op=PAM:session_open
> > acct="root" exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron
> > res=failed)'
> > ----
> > time->Fri Jan 28 05:30:02 2011
> > type=USER_END msg=audit(1296192602.124:2920): user pid=2652 uid=0
> > auid=4294967295 ses=4294967295
> > subj=system_u:system_r:crond_t:s0-s15:c0.c255 msg='op=PAM:session_close
> > acct="root" exe="/usr/sbin/crond" (hostname=?, addr=?, terminal=cron
> > res=failed)'
> > 
> > How to debug this crond PAM issue?
> 
> I don't see any SELinux audit messages. You could try adding
> logging_set_loginuid(crond_t), which you'll need from a SELinux policy
> perspective, but there may be non-SELinux reasons it doesn't work.
> 
> I have merged the third patch.
> 
 
Many thanks for your reply, Chirs!
 
I will take more time on your comments on the 2nd patch. As for the 3rd one, I still have one more question.
 
I have been puzzled by the question of how the cron job process domain has been decided. In vixie-cron-4.1, the crond gets the seuser name for the user of the pending crontab command by the getseuserbyname() function, then gets the context for the cron job process by the get_default_context_with_level() function, which in turn will read the contexts/users/[user] and contexts/default_contexts files.
 
The getdefaultcon command could serve the same purpose:
 
[root/sysadm_r/s0 at qemu-client contexts]# getdefaultcon staff_u system_u:system_r:crond_t:s0
staff_u:staff_r:cronjob_t:s0
[root/sysadm_r/s0 at qemu-client contexts]# getdefaultcon user_u system_u:system_r:crond_t:s0
user_u:user_r:cronjob_t:s0
[root/sysadm_r/s0 at qemu-client contexts]# 
 
As we can see, staff_u/user_u's cron job process would be in cronjob_t domain, different than their contexts of staff_t/user_t, I am not sure, but it's possible that cronjob_t could have more priviledges than staff_t/user_t,  which seems to be not desirable priviledge escalation. Is this correct?
 
BTW, could we make cron job process in the same domain as the user's login shell, by changing users/[user] files, say "staff_r:cronjob_t:s0" -> "staff_r:staff_t:s0" ? Would this make sense?
 
Thanks!
 
Best regards,
Harry
 
 

> -- 
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110202/0207938c/attachment.html