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