Bug 473036 - (staff_u) SELinux is preventing sudo (staff_sudo_t) "link" system_crond_t.
(staff_u) SELinux is preventing sudo (staff_sudo_t) "link" system_crond_t.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
11
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Howells
Fedora Extras Quality Assurance
: SELinux
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-26 03:14 EST by Matěj Cepl
Modified: 2010-06-28 06:50 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 06:50:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matěj Cepl 2008-11-26 03:14:54 EST
SELinux is preventing sudo (staff_sudo_t) "link" system_crond_t.

Podrobný popis:

SELinux denied access requested by sudo. It is not expected that this access is
required by sudo and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access.

Povolení přístupu:

You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Další informace:

Kontext zdroje                staff_u:staff_r:staff_sudo_t:SystemLow-SystemHigh
Kontext cíle                 system_u:system_r:system_crond_t:SystemLow-
                              SystemHigh
Objekty cíle                 None [ key ]
Zdroj                         sudo
Cesta zdroje                  /usr/bin/sudo
Port                          <Neznámé>
Počítač                    viklef
RPM balíčky zdroje          sudo-1.6.9p17-2.fc10
RPM balíčky cíle           
RPM politiky                  selinux-policy-3.5.13-26.fc10
Selinux povolen               True
Typ politiky                  targeted
MLS povoleno                  True
Vynucovací režim            Enforcing
Název zásuvného modulu     catchall
Název počítače            viklef
Platforma                     Linux viklef 2.6.27.5-120.fc10.i686 #1 SMP Tue Nov
                              18 20:12:41 EST 2008 i686 i686
Počet upozornění           1
Poprvé viděno               St 26. listopad 2008, 08:01:20 CET
Naposledy viděno             St 26. listopad 2008, 08:01:20 CET
Místní ID                   3358266b-e0f1-4c73-83f0-a335373900f0
Čísla řádků              

Původní zprávy auditu      

node=viklef type=AVC msg=audit(1227682880.512:23): avc:  denied  { link } for  pid=3444 comm="sudo" scontext=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_crond_t:s0-s0:c0.c1023 tclass=key

node=viklef type=SYSCALL msg=audit(1227682880.512:23): arch=40000003 syscall=288 success=no exit=-13 a0=8 a1=fffffffc a2=fffffffd a3=0 items=0 ppid=3386 pid=3444 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="sudo" exe="/usr/bin/sudo" subj=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 key=(null)

=====================================================
Not sure what is the problem. Happened just once when logging in to Gnome session. Just to provide some information, here is crontab -l output ...

Well, there isn't, when tried to run crontab -l as staff_u user I got this AVC denial:


Souhrn:

SELinux is preventing crontab (staff_crontab_t) "read" to ./matej
(cron_spool_t).

Podrobný popis:

SELinux denied access requested by crontab. It is not expected that this access
is required by crontab and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Povolení přístupu:

Sometimes labeling problems can cause SELinux denials. You could try to restore
the default system file context for ./matej,

restorecon -v './matej'

If this does not work, there is currently no automatic way to allow this access.
Instead, you can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Další informace:

Kontext zdroje                staff_u:staff_r:staff_crontab_t:SystemLow-
                              SystemHigh
Kontext cíle                 unconfined_u:object_r:cron_spool_t
Objekty cíle                 ./matej [ file ]
Zdroj                         crontab
Cesta zdroje                  /usr/bin/crontab
Port                          <Neznámé>
Počítač                    viklef
RPM balíčky zdroje          cronie-1.2-4.fc10
RPM balíčky cíle           
RPM politiky                  selinux-policy-3.5.13-26.fc10
Selinux povolen               True
Typ politiky                  targeted
MLS povoleno                  True
Vynucovací režim            Enforcing
Název zásuvného modulu     catchall_file
Název počítače            viklef
Platforma                     Linux viklef 2.6.27.5-120.fc10.i686 #1 SMP Tue Nov
                              18 20:12:41 EST 2008 i686 i686
Počet upozornění           1
Poprvé viděno               St 26. listopad 2008, 09:12:12 CET
Naposledy viděno             St 26. listopad 2008, 09:12:12 CET
Místní ID                   a7b0c175-95d4-4f93-a72c-fe15355dda73
Čísla řádků              

Původní zprávy auditu      

node=viklef type=AVC msg=audit(1227687132.3:41): avc:  denied  { read } for  pid=4211 comm="crontab" name="matej" dev=dm-0 ino=1275534 scontext=staff_u:staff_r:staff_crontab_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:cron_spool_t:s0 tclass=file

node=viklef type=SYSCALL msg=audit(1227687132.3:41): arch=40000003 syscall=5 success=no exit=-13 a0=bfae4d2c a1=0 a2=1b6 a3=0 items=0 ppid=4183 pid=4211 auid=500 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="crontab" exe="/usr/bin/crontab" subj=staff_u:staff_r:staff_crontab_t:s0-s0:c0.c1023 key=(null)

=================================

OK, I had to get it as root:

[root@viklef ~]# crontab -u matej -l
*/1 * * * *       /usr/local/bin/fortune > $HOME/.signature-thunderbird 2>&1
[root@viklef ~]#
Comment 1 Matěj Cepl 2008-11-26 08:28:22 EST
Happens whenever I switch with sudo to being a root.
Comment 2 Daniel Walsh 2008-11-27 06:58:27 EST
These seems to be two bugs here.

One is you have a mislabeled crontab file.  restorecon can not fix this.

chcon -t staff_u:object_r:staff_cron_spool_t  /var/spool/cron/matej 

will fix the crontab -l problem.


The link problem is a bug in the way the kernel is handling keyrings.
Comment 3 Daniel Walsh 2008-11-27 06:59:13 EST
sudo is not trying to read cron cron key files this is a bug in the kernel, I believe.
Comment 4 Matěj Cepl 2008-11-27 08:17:31 EST
[root@hubmaier ~]# LANG=C chcon -t staff_u:object_r:staff_cron_spool_t  /var/spool/cron/matej 
chcon: failed to set type security context component to `staff_u:object_r:staff_cron_spool_t': Invalid argument
[root@hubmaier ~]# id
uid=0(root) gid=0(root) skupiny=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh
[root@hubmaier ~]#
Comment 5 Matěj Cepl 2008-11-27 08:45:15 EST
(In reply to comment #4)
> [root@hubmaier ~]# LANG=C chcon -t staff_u:object_r:staff_cron_spool_t 
> /var/spool/cron/matej 
> chcon: failed to set type security context component to
> `staff_u:object_r:staff_cron_spool_t': Invalid argument
> [root@hubmaier ~]# id
> uid=0(root) gid=0(root)
> skupiny=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
> context=unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh
> [root@hubmaier ~]#

Shut, wrong computer! Of course, on the computer with staff_u enabled this command works perfectly OK.
Comment 6 Bug Zapper 2009-06-09 05:56:00 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Bug Zapper 2010-04-27 08:22:34 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Bug Zapper 2010-06-28 06:50:09 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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