AW: RHEL5 + strict policy: Unprivileged user cron - "Unauthorized SELinux context"

[Harald Beugler-Bell]

I got a similar problem when trying to run cron as root. It looks like selinux is unable
to get the correct user context of the crond process

crond[5587]: (*system*) NULL security context for user ()
crond[5587]: CRON (root) ERROR: failed to change SELinux context
crond[5587]: CRON (root) ERROR: cannot set security context

The file context of the cron file is set according to default context:
$ ls -lZ /etc/cron.d/testing-cron
-rw-r--r--  root root system_u:object_r:system_cron_spool_t:s0 /etc/cron.d/testing-cron

$ ps -efZ | grep crond
staff_u:system_r:crond_t:s0     root     14922     1  0 00:19 ?        00:00:00
/usr/sbin/crond start

$ /usr/sbin/semanage login -l | egrep "root|system"

root                      root                      s0-s0:c0.c1023

system_u                  system_u                  s0-s0:c0.c1023

bash-3.1# cat /etc/redhat-release

Red Hat Enterprise Linux Server release 5 (Tikanga)
vixie-cron-4.1-66.1.el5
libselinux-1.33.4-2.el5
libselinux-python-1.33.4-2.el5
selinux-policy-strict-2.4.6-79.el5
selinux-policy-2.4.6-79.el5

any help is welcome.

thanks
Hari

----- Ursprüngliche Mail ----
Von: Aleksander Adamowski <aleksander.adamowski.fedora(a)altkom.pl&gt;
An: fedora-selinux-list(a)redhat.com
Gesendet: Mittwoch, den 28. November 2007, 16:10:58 Uhr
Betreff: Re: RHEL5 + strict policy: Unprivileged user cron - "Unauthorized SELinux
context"

Stephen Smalley pisze:
>  On Wed, 2007-11-28 at 21:16 +0100, Aleksander Adamowski wrote:
>    
> > crond[27249]: (apache) Unauthorized SELinux context, but SELinux in 
> > permissive mode, continuing (cron/apache)
> > crond[29358]: (apache) NULL security context for user, but SELinux 
 in 
> > permissive mode, continuing ()
> >     
>
>  Sounds like it just stayed in crond's context since it failed the 
 check
>  and the system was permissive.  Naturally, in enforcing mode, it
 would
>  have not executed the job at all.
>
>  crond computes a context for the user's cron job in the usual manner,
>  then applies a entrypoint permission check between that context and 
 the
>  file context on the crontab file (which gets picked up from a
>  combination of its creator and the parent directory).  If that check
>  fails, then crond refuses to execute the crontab commands in that
>  process context.  The check is intended to prevent injection of 
 commands
>  from one context into another via crontab, unless authorized by
 policy
>  of course.
>     
That's reasonable.
>  I'd have expected it to try to run the cron job in
> user_u:user_r:
>  user_crond_t:s0 since apache wouldn't have a specific entry in 
 seusers.
>  So it would have wanted the crontab file to have user_cron_spool_t
> on
>  it, which would have happened if a user_t process created it.  If
>  instead an admin created it and it got sysadm_cron_spool_t or
>  staff_cron_spool_t, that might explain it.  So you could relabel it 
 or
>  allow that permission.  First though check the current label on the
>  crontab file.
>     
Yes, you're right. That was precisely the cause.
I've used "crontab -e -u apache" as root.
The files in /var/spool/cron got sysadm_cron_spool_t type (the full 
context was root:object_r:sysadm_cron_spool_t).

After running "fixfiles relabel /var/spool/cron/", the apache crontab 
got system_u:object_r:user_cron_spool_t.

Now cron runs fine and doesn't log anything suspicious.

IMHO crontab should be modified to relabel crontab files that are
 edited 
using the "-u" option, but this is a question to Dan - should I file a 
new bug to bugzilla.redhat.com on this?

-- 
Best Regards,
    Aleksander Adamowski
        GG#: 274614
        ICQ UIN: 19780575 
    http://olo.org.pl

--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list





	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Harald Beugler-Bell wrote:
>  I got a similar problem when trying to run cron as root. It looks
> like selinux is unable to get the correct user context of the crond process
>  
>  crond[5587]: (*system*) NULL security context for user ()
>  crond[5587]: CRON (root) ERROR: failed to change SELinux context
>  crond[5587]: CRON (root) ERROR: cannot set security context
>  
>  The file context of the cron file is set according to default context:
>  $ ls -lZ /etc/cron.d/testing-cron
>  -rw-r--r--  root root system_u:object_r:system_cron_spool_t:s0 /etc/cron.d/testing-cron
>  
>  $ ps -efZ | grep crond
>  staff_u:system_r:crond_t:s0     root     14922     1  0 00:19 ?        00:00:00
> /usr/sbin/crond start
>  
>  $ /usr/sbin/semanage login -l | egrep "root|system"
>  
>  root                      root                      s0-s0:c0.c1023
>  
>  system_u                  system_u                  s0-s0:c0.c1023
>  
>  bash-3.1# cat /etc/redhat-release
>  
>  Red Hat Enterprise Linux Server release 5 (Tikanga)
>  vixie-cron-4.1-66.1.el5
>  libselinux-1.33.4-2.el5
>  libselinux-python-1.33.4-2.el5
>  selinux-policy-strict-2.4.6-79.el5
>  selinux-policy-2.4.6-79.el5
>  
>  any help is welcome.
>  
>  thanks
>  Hari
>  
>  ----- Ursprüngliche Mail ----
>  Von: Aleksander Adamowski <aleksander.adamowski.fedora(a)altkom.pl&gt;
>  An: fedora-selinux-list(a)redhat.com
>  Gesendet: Mittwoch, den 28. November 2007, 16:10:58 Uhr
>  Betreff: Re: RHEL5 + strict policy: Unprivileged user cron - "Unauthorized SELinux
> context"
>  
>  Stephen Smalley pisze:
> > On Wed, 2007-11-28 at 21:16 +0100, Aleksander Adamowski wrote:
> >   
> >> crond[27249]: (apache) Unauthorized SELinux context, but SELinux in 
> >> permissive mode, continuing (cron/apache)
> >> crond[29358]: (apache) NULL security context for user, but SELinux
>   in 
> >> permissive mode, continuing ()
> >>     
> > Sounds like it just stayed in crond's context since it failed the
>   check
> > and the system was permissive.  Naturally, in enforcing mode, it
>   would
> > have not executed the job at all.
> >
> > crond computes a context for the user's cron job in the usual manner,
> > then applies a entrypoint permission check between that context and
>   the
> > file context on the crontab file (which gets picked up from a
> > combination of its creator and the parent directory).  If that check
> > fails, then crond refuses to execute the crontab commands in that
> > process context.  The check is intended to prevent injection of
>   commands
> > from one context into another via crontab, unless authorized by
>   policy
> > of course.
> >   
>  That's reasonable.
> > I'd have expected it to try to run the cron job in user_u:user_r:
> > user_crond_t:s0 since apache wouldn't have a specific entry in
>   seusers.
> > So it would have wanted the crontab file to have user_cron_spool_t on
> > it, which would have happened if a user_t process created it.  If
> > instead an admin created it and it got sysadm_cron_spool_t or
> > staff_cron_spool_t, that might explain it.  So you could relabel it
>   or
> > allow that permission.  First though check the current label on the
> > crontab file.
> >   
>  Yes, you're right. That was precisely the cause.
>  I've used "crontab -e -u apache" as root.
>  The files in /var/spool/cron got sysadm_cron_spool_t type (the full 
>  context was root:object_r:sysadm_cron_spool_t).
>  
>  After running "fixfiles relabel /var/spool/cron/", the apache crontab 
>  got system_u:object_r:user_cron_spool_t.
>  
>  Now cron runs fine and doesn't log anything suspicious.
>  
>  IMHO crontab should be modified to relabel crontab files that are
>   edited 
>  using the "-u" option, but this is a question to Dan - should I file a 
>  new bug to bugzilla.redhat.com on this?
>   
Please update to the U1 policy.

I think you should be able to get this from RHN or you can grab it off of
http://people.redhat.com/dwalsh/SELinux/RHEL5

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFHVCxErlYvE4MpobMRAhI4AKDNDDa5Nmz0D1hzlneVDMwrCoV6jwCfWCwd
> lrYMtBD3xAYpoQ8CFlH8sWM=
> =H/J2
> -----END PGP SIGNATURE-----

[Aleksander Adamowski]

Daniel J Walsh pisze:
>  Please update to the U1 policy.
>
>  I think you should be able to get this from RHN or you can grab it off of
>  http://people.redhat.com/dwalsh/SELinux/RHEL5
>
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.7 (GNU/Linux)
> >  Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> >
> >  iD8DBQFHVCxErlYvE4MpobMRAhI4AKDNDDa5Nmz0D1hzlneVDMwrCoV6jwCfWCwd
> >  lrYMtBD3xAYpoQ8CFlH8sWM=
> >  =H/J2
> >  -----END PGP SIGNATURE----- 
>     
It seems OK now, when I use "crontab -e
-u unprivileged_user", the 
created crontab file looks like this:

$ ls -lZ /var/spool/cron/unprivileged_user
-rw-------  root root root:object_r:sysadm_cron_spool_t 
/var/spool/cron/unprivileged_user

The version I have is:

$ rpm -q selinux-policy-strict
selinux-policy-strict-2.4.6-106.el5_1.3


-- 
Best Regards,
    Aleksander Adamowski
        GG#: 274614
        ICQ UIN: 19780575 
	http://olo.org.pl

--
Aleksander Adamowski
    Administrator systemów korporacyjnych; Instruktor
    Altkom Akademia S.A. http://www.altkom.pl
    Warszawa, ul. Chłodna 51
    
    kom. 0-601-318-080

Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru
Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN.  Adres rejestrowy
Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa
firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych
celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne
skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości.
This message contains proprietary information and trade secrets of Altkom Akademia S.A.
company.
Unauthorized use or disclosure of this information to any third party is prohibited.
If you received this message by mistake, please contact the sender immediately and delete
all copies of this message.