Bug 460873

Following the reproducer:
setenforce 1
/var/log/messages
Sep  3 10:11:33 caladan atd[2768]: Not allowed to set exec context to user_u:user_r:system_chkpwd_t:s0 for user  marca#012: No such file or directory

/var/log/audit is attached as audit.log

setenforce 0
nothing in /var/log/messages
/var/log/audit is attached as audit2.log

Created attachment 315625 [details]
audit

Created attachment 315626 [details]
audit

You can add these rules for now using

# grep avc /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Fixed in selinux-policy-3.3.1-88.fc9

Eh, Daniel, exactly what did you add to "fix" this in 3.3.1-88.fc9?

Note that in the first audit log (315625) there are NO avc messages.  And that is the case that fails.

In the second audit log there are avc failures.  And it might be that those would actually have blocked the functionality if they had been enforced.  But in enforcing mode the application doesn't even try those operations!

I maintain that the primary problem here is in the application (at), not in the policy.  And I suspect the patch to the upstreams package that adds a lot of SELinux aware code.  In particular, there are several tests to check if the mode is enforcing or not.  So the application is actually programmed to behave differently in enforcing and permissive mode.

When this problem is fixed, there may or may not be things that have to be changed in the policy too.

I have allowed sendmail to read cron spool files.

Policy is now available in koji if you want to try it out.

I picked up selinux-policy-3.3.1-90.fc9 from Koji.  I still don't get any mail.  In permissive mode, I no longer get any avc denials, but in enforcing mode no mail is delivered anyway.

I still believe this is a bug in at, not in selinux-policy.

Sorry, I didn't mean to take you out of the loop Daniel.  That was an unintentional side-effect when I assigned the bug back to the at component.

Anyway, I downloaded at-debuginfo and made a bit of debugging.  What happens is this:

The command gets executed properly and a file with the intended mail message is created.  But things gets wrong when this mail is to be sent.  The relevant code is in the "if ( mail_pid == 0 )" of run_file() in atd.c.

First it does a
   get_default_context("myuser", NULL, &user_context)
and gets "user_u:user_r:system_chkpwd_t" in user_context.  (Is this correct?  Should system_chkpwd_t be the type one gets as the default?)

Then it does an
   fgetfilecon(STDIN_FILENO, &file_context)
and gets "unconfined_u:object_r:cron_spool_t" back.  Standard input contains the message that is to be sent.

In the next step it checks to see if this user is allowed to enter(!) this file:
   security_compute_av(user_context,file_context,SECCLASS_FILE,FILE__ENTRYPOINT,&avd);
In the result, avd.allowed=0.  The code then verifies that FILE__ENTRYPOINT is in avd.allowed, which it isn't, and gives up instead of sending the mail.

I'm not sure if the syste_chkpwd_t default context is corret, or if I have made some mistake which makes this the default.  But in any case it doesn't seem sensible to test for entrypoint permission to the file which contains the message to be sent.  That is pure data!

Created attachment 316674 [details]
Attempted module to allow the accesses.

I tried to make a policy to verify my reasoning.  By allowing system_chkpwd_t entrypoint access to cron_spool_t:file the code doesn't stop, and launches sendmail to send the message.  But first it does an setexeccon() to system_chkpwd_t, and that domain is what sendmail runs in.  That doesn't work too well it seems.  I tried to make the process transition into the sendmail_t domain when executing sendmail, but I must be doing something wrong.

But this isn't too important, I guess.  This shouldn't be allowed, the bug is in the atd code which requests it to be allowed.  Or am I completely confused here?

No it should not be running in system_chkpwd_t.

What does 
id -Z 
when you setup cron job?

# semanage login -l
# semanage user -l

When I ran "id -Z as a cron job, I get

unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh

The other commands below:

mimmi# env LANG=en_US.utf8 semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               unconfined_u              SystemLow-SystemHigh     
root                      unconfined_u              s0-s0:c0.c255            
system_u                  system_u                  SystemLow-SystemHigh     

mimmi# env LANG=en_US.utf8 semanage user -l

                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

root            user       s0         SystemLow-SystemHigh           system_r staff_r unconfined_r sysadm_r
staff_u         user       s0         SystemLow-SystemHigh           system_r staff_r sysadm_r
sysadm_u        user       s0         SystemLow-SystemHigh           sysadm_r
system_u        user       s0         SystemLow-SystemHigh           system_r
unconfined_u    unconfined s0         SystemLow-SystemHigh           system_r unconfined_r
user_u          user       s0         s0                             user_r

Created attachment 316856 [details]
Rewrote the SELinux patch to be shared between the job and the email

Please apply this patch to F9/Rawhide.

Not sure if this is broken in RHEL5 also.

Thank you for the patch.

at-3.1.10-24.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/at-3.1.10-24.fc9

I picked up at-3.1.10-24.fc9 from Koji and tried it, and it worked fine!  I got the expected mail this time.

I did make a try on my RHEL5 desktop at work, and it does NOT seem to have the problem.  (at-3.1.8-82.fc6)

at-3.1.10-24.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update at'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8251

*** Bug 460252 has been marked as a duplicate of this bug. ***

at-3.1.10-24.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

at-3.1.10-24.fc9 works fine.

I did note that at-3.1.10-24.fc10 does not work.  I thought it was the same "24", but apparently it's different branches somehow.  Just thought I'd mention it so this doesn't reappear in F10 by mistake.  (RPM considers at-3.1.10-24.fc10 newer than at-3.1.10-24.fc9.)