Bug 426704 - /var/run/ctlinndXXXXX created with policy unconfined_u
/var/run/ctlinndXXXXX created with policy unconfined_u
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-24 13:25 EST by Need Real Name
Modified: 2008-02-07 16:01 EST (History)
2 users (show)

See Also:
Fixed In Version: 4.2-7.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-07 16:01:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/etc/selinux (2.26 MB, application/octet-stream)
2008-01-24 18:26 EST, Need Real Name
no flags Details

  None (edit)
Description Need Real Name 2007-12-24 13:25:50 EST
Description of problem:
Starting/stopping news gives avc error:

type=AVC msg=audit(1198488939.602:2299): avc:  denied  { sendto } for  pid=3136
comm="innd" path="/var/run/news/ctlinndvCPan4"
scontext=system_u:system_r:innd_t:s0
tcontext=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_dgram_socket

ls -Z /var/run/news:
srwxrwxr-x  news news system_u:object_r:innd_var_run_t:s0 control
srwxrwxrwx  news news unconfined_u:object_r:innd_var_run_t:s0 ctlinndQhXMDu
-rw-rw-r--  news news system_u:object_r:innd_var_run_t:s0 innd.pid
srwxrwxr-x  news news system_u:object_r:innd_var_run_t:s0 nntpin
Comment 1 Daniel Walsh 2007-12-31 08:03:56 EST
This looks like you have a unconfined_u process that owns ctlinndQhXMDu

Did you run the news server direclty?  Do you have a innd process running as
unconfined_t?

Can you run lsof to figure out what process has ctlinndQhXMDu
 open?
Comment 2 Need Real Name 2007-12-31 13:21:08 EST
OK - did some sleuthing.
This error is generated daily by the cron.daily process inn-cron-expire which in
turn calls the script "/usr/lib/news/bin/news.daily" which then in turn calls
the function ctlinnd generating the selinux error.

However, the cron.daily scripts are run as unconfined_u and hence everything
launched downstream is also unconfined_u:

The following is the ouptut of ps --context:

23381 unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 /bin/sh
/etc/cron.daily/inn-cron-expire
23385 unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 awk -v
progname=/etc/cron.daily/inn-cron-expire progname {?????   print progname
":\n"?????   progname="";????       }????       { print; }
23384 unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 runuser - news -c unset
LANG; unset LC_COLLATE; /usr/lib/news/bin/news.daily delayrm
23386 unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 -sh -c unset LANG; unset
LC_COLLATE; /usr/lib/news/bin/news.daily delayrm

So, it would seem that this error should occur for anybody who has installed the
standard Fedora inn package since it includes the cron.daily script mentioned abvoe.

-----------------------------------------------------------
This is probably not relevant now, but here is the output of 
lsof at the time when the script runs:
COMMAND  PID USER   FD   TYPE DEVICE   SIZE    NODE NAME
ctlinnd 9513 news  cwd    DIR    8,7   4096 1684580 /etc/news
ctlinnd 9513 news  rtd    DIR    8,7   4096       2 /
ctlinnd 9513 news  txt    REG    8,7  48260 1032748 /usr/lib/news/bin/ctlinnd
ctlinnd 9513 news  mem    REG    8,7 128952 1357441 /lib/ld-2.7.so
ctlinnd 9513 news    0u   CHR  136,1              3 /dev/pts/1
ctlinnd 9513 news    1w  FIFO    0,6        1532699 pipe
ctlinnd 9513 news    2w  FIFO    0,6        1532699 pipe
ctlinnd 9513 news    3u   CHR  136,1              3 /dev/pts/1
Comment 3 Daniel Walsh 2007-12-31 15:14:59 EST
ls -lZ /etc/cron.daily/inn*


If the owner is unconfined_u can you change it to system_u

chcon -u unconfined_u  /etc/cron.daily/inn-cron-expire 
Comment 4 Need Real Name 2007-12-31 15:53:24 EST
(First, I assume you meant chcon -u system_u to be consistent with your previous
sentence)

ls -lZ /etc/cron.daily/inn*

-rwxr-xr-x  root root system_u:object_r:bin_t:s0      
/etc/cron.daily/inn-cron-expire*

So, that doesn't seem to be the problem...
In fact all the cron-related files in /etc are already system_u
Comment 5 Need Real Name 2007-12-31 16:09:21 EST
Also, just checked several of the other cron.hourly scripts using ps --context
They all seem to run as unconfined_u:system_r:unconfined_t

Though the cron process itself does not:
2851 system_u:system_r:crond_t:s0-s0:c0.c1023 crond

and the /etc/ cron files all have system_u context as mentioned previously

-rw-r--r--  root root system_u:object_r:system_cron_spool_t:s0 /etc/crontab
-rw-r--r--  root root system_u:object_r:etc_t:s0       /etc/sysconfig/crontab
-rw-r--r--  root root system_u:object_r:etc_t:s0       /etc/anacrontab


drwxr-xr-x  root root system_u:object_r:etc_t:s0       /etc/cron.weekly
-rwxr-xr-x  root root system_u:object_r:bin_t:s0       /etc/cron.daily/inn-cron-
expire
drwxr-xr-x  root root system_u:object_r:etc_t:s0       /etc/cron.hourly
-rwxr-xr-x  root root system_u:object_r:bin_t:s0      
/etc/cron.hourly/inn-cron-rnews
-rwxr-xr-x  root root system_u:object_r:bin_t:s0      
/etc/cron.hourly/inn-cron-nntpsend
-rw-r--r--  root root system_u:object_r:etc_t:s0       /etc/cron.deny
drwxr-xr-x  root root system_u:object_r:etc_t:s0       /etc/cron.monthly
Comment 6 Daniel Walsh 2007-12-31 17:34:25 EST
# semanage login -l | grep system_u
Comment 7 Need Real Name 2007-12-31 18:50:33 EST
Login Name                SELinux User              MLS/MCS Range            

__default__               unconfined_u              s0-s0:c0.c1023           
root                      system_u                  s0-s0:c0.c1023 
Comment 8 Need Real Name 2007-12-31 19:01:10 EST
Also as a side-note -- my selinux setup is pretty pristine in that I have not
(yet) started adding my own local stuff since I have been waiting first to see
how many of the "bugs" get shaken out publicly first (hence my many bugzilla
reports :)

Also, this particular selinux issue tracks back (via my log files) to the
initial installation (actually the first day after when cron ran). So, it really
represents a very pristine state of my system.
Comment 9 Daniel Walsh 2008-01-03 11:02:24 EST
ps -eZ | grep cron
Comment 10 Need Real Name 2008-01-03 11:12:09 EST
system_u:system_r:crond_t:s0-s0:c0.c1023 2842 ? 00:00:00 crond
system_u:system_r:crond_t:s0-s0:c0.c1023 2881 ? 00:00:00 atd

(actually I already gave you the 'crond' line as part of Comment #5 :)

So, as mentioned in that previous comment, it seems that the individual
cron.daily/hourly/etc scripts run as unconfined_u:system_r:unconfined_t even
though the parent process (crond) and the file locations themselves are system_u
and crond_t/bin_t respectively.
Comment 11 Daniel Walsh 2008-01-03 14:40:43 EST
Yes I am trying to understand why.  On my Fedora 8 box they are running as
system_u:system_r:system_crond_t  not unconfined_u

Which is what they are supposed to run as.
Comment 12 Need Real Name 2008-01-03 15:07:50 EST
I'm stumped -- let me know what else I can do troubleshoot this...
Comment 13 Need Real Name 2008-01-16 11:08:29 EST
I did some experimenting and it seems like ANY command run even directly from
/etc/crontab gets run as:
 unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023

My /etc/crontab is the stock fedora crontab.

Again, the crond process itself runs as:
 system_u:system_r:crond_t:s0-s0:c0.c1023 crond

And /etc/crontab has context:
 system_u:object_r:system_cron_spool_t:s0

Also, the file /etc/selinux/targeted/contexts/users/root has the following line:
  system_r:crond_t:s0     system_r:unconfined_t:s0 sysadm_r:sysadm_crond_t:s0
staff_r:staff_crond_t:s0 user_r:user_crond_t:s0

I don't know what else to troubleshoot since this is as stripped down as I can
think of. I'm sure it's something simple but I don't know enough about how
processes get or change their selinux context to explore any further.

Thanks!
Comment 14 Need Real Name 2008-01-17 11:01:09 EST
Dan,
Are you *sure* that crond processes on an unmodified system run as
"system_u:system_r:system_crond_t"?

Because I just created a VIRGIN F8 virtual machine using the Fedora installer
with only default options and packages selected. I logged in and made only the
following changes:
  yum update "selinux*"

  Edited the crontab to add the line:
  * * * * * root /usr/bin/wc /boot/vmlinuz

and then ran in a terminal:
 while [ "1" ] ; do ps --context --no-headers -C wc ; done

The result was again:
 unconfined_u:system_r:unconfined_t

I'm not sure how much more basic and virgin I can be then that to confirm that
there does seem to be something wrong here.

Is it possible that you have changed something on YOUR configuration that masks
this error?


    
Comment 15 Need Real Name 2008-01-17 11:03:52 EST
Just to clarify - I am talking about the process launched by crond running as
unconfined_u:system_r:unconfined_t.
The crond daemon itself runs as:
system_u:system_r:crond_t:s0-s0:c0.c1023
Comment 16 Daniel Walsh 2008-01-24 16:11:48 EST
Could you tar up /etc/selinux and send put it somewhere I can pull it from.

I have no idea why this is happening to you, but would like to see if I can get
it to happen here.

Comment 17 Need Real Name 2008-01-24 18:25:29 EST
Sure - but still don't understand why I also had the problem on a virgin system
created on a new virtual machine. For the virgin test case, I did a completely
default install of Fedora 8 and then other than yum updating selinux (to make
sure I had the latest), I did absolutely no changes or customizations. I just
added a cron line to /etc/crontab and then ran a ps loop on it to catch it in
the act.

Anyway I will attach my /etc/selinux as a tarred/compressed attachment
Comment 18 Need Real Name 2008-01-24 18:26:55 EST
Created attachment 292881 [details]
/etc/selinux
Comment 19 Stephen Smalley 2008-01-25 09:20:43 EST
crond looks up the fake user "system_u" for system cron jobs when computing the
right security context for the job, while using the Linux username for user cron
jobs.  Originally, this was a direct get_default_context() call on the username,
but with the introduction of seusers, it became a call to getseuserbyname()
followed by a call to get_default_context.  Implication:  crond requires
system_u Linux user to be mapped to system_u SELinux user in the seusers file in
order to work.  Or, alternatively, crond needs to be fixed to _not_ call
getseuserbyname() when handling system_u aka system cron jobs.
So, bug in policy _or_ bug in vixie-cron, depending on your point of view.
Comment 20 Stephen Smalley 2008-01-25 09:47:01 EST
In vixie-cron sources, src/user.c:load_user() calls get_security_context() with
"system_u" if pw is NULL, otherwise it passes the uname.  get_security_context()
then calls getseuserbyname() followed by get_default_context_with_level() to map
the Linux user to a SELinux user/level pair and then to map the SELinux
user/level pair to a full context.

Suggestion:  load_user() to pass NULL if pw is NULL, and change
get_security_context() to handle a NULL name by directly calling
get_default_context() on "system_u" rather than calling getseuserbyname at all.
 Then we don't need a system_u entry in seusers.
Comment 21 Daniel Walsh 2008-01-25 16:40:14 EST
Ok for now add the mapping.

semanage login -a -s system_u  -r s0-s0:c0.c1023 system_u
Comment 22 Need Real Name 2008-01-26 18:02:26 EST
Dan, just out of curiousity, what was the reason that you were not able to
reproduce this "bug" on your machine?
Comment 23 Daniel Walsh 2008-01-28 14:47:28 EST
Because I have the mapping.

 semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               unconfined_u              s0-s0:c0.c1023           
dwalsh                    staff_u                   s0                       
root                      unconfined_u              s0-s0:c0.c1023           
system_u                  system_u                  s0-s0:c0.c1023  


I missed this when you output the command.
Comment 24 Stephen Smalley 2008-01-28 14:53:01 EST
Suggest reassigning bug to cron to get the cron logic changed to avoid need for
that mapping.
Comment 25 Marcela Mašláňová 2008-01-29 11:17:33 EST
I've reproduced it and I'm working on it. Thank you for report and suggestions.
Comment 26 Fedora Update System 2008-01-31 03:20:36 EST
vixie-cron-4.2-7.fc8 has been submitted as an update for Fedora 8
Comment 27 Fedora Update System 2008-02-01 20:19:26 EST
vixie-cron-4.2-7.fc8 has been pushed to the Fedora 8 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 vixie-cron'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1218
Comment 28 Fedora Update System 2008-02-07 16:01:36 EST
vixie-cron-4.2-7.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.