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?

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

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 

(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

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

# semanage login -l | grep system_u

Login Name                SELinux User              MLS/MCS Range            

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

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.

ps -eZ | grep cron

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.

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.

I'm stumped -- let me know what else I can do troubleshoot this...

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!

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?


    

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

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.

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

Created attachment 292881 [details]
/etc/selinux

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.

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.

Ok for now add the mapping.

semanage login -a -s system_u  -r s0-s0:c0.c1023 system_u

Dan, just out of curiousity, what was the reason that you were not able to
reproduce this "bug" on your machine?

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.

Suggest reassigning bug to cron to get the cron logic changed to avoid need for
that mapping.

I've reproduced it and I'm working on it. Thank you for report and suggestions.

vixie-cron-4.2-7.fc8 has been submitted as an update for Fedora 8

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

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.