Re: Why cron doesn't work in strict policy

Re: Why cron doesn't work in strict policy

[Daniel J Walsh]

Ivan Gyurdiev wrote:
>
>>
>> cron ---> getseuserbyname(system_u)
>> selinux <--- (user_u, s0)
>> cron ---> get_default_context_with_level(user_u, s0)
>> selinux <--- (user_u:user_r:user_xserver_t) (????)
>> cron ---> security_compute_av(user_u:user_r:user_xserver_t, 
>> system_u:object_r:system_cron_spool_t)
>> selinux <-- not allowed
>>
>> The problem comes from system_u being mapped to __default__ in the 
>> seusers file, although I have no idea why (user_u, s0) would return 
>> default context of user_xserver_t either.
> So for using system cronfiles, the getseuserbyname() call needs to be 
> skilled (since you've already decided on the user - system_u, user.c: 
> line 87). Not sure about level. Alternatively you can query using root.
Seems to me we have two choices.  One is to change cron to default to 
"root" when there is no username or to add system_u to the seusers file.

Right now cron has the following code in it.

    if (get_security_context(pw == NULL ? "system_u" : uname,
                 crontab_fd,
                 &u->scontext, tabname) != 0) {
        free_user(u);
        u = NULL;
        goto done;
    }
   


get_security_context()
...
    if (getseuserbyname(name, &seuser, &level) == 0) {
        retval=get_default_context_with_level(seuser, level, NULL, 
&scontext);
        free(seuser);
        free(level);
        if (retval) {
...

Which causes cron jobs on strict policy and I would guess MLS to run at 
user_u since system_u is not defined and would run at level s0. 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Why cron doesn't work in strict policy

[Ivan Gyurdiev]

>>> cron ---> getseuserbyname(system_u)
>>> selinux <--- (user_u, s0)
>>> cron ---> get_default_context_with_level(user_u, s0)
>>> selinux <--- (user_u:user_r:user_xserver_t) (????)
>>> cron ---> security_compute_av(user_u:user_r:user_xserver_t, 
>>> system_u:object_r:system_cron_spool_t)
>>> selinux <-- not allowed
>>>
>>> The problem comes from system_u being mapped to __default__ in the 
>>> seusers file, although I have no idea why (user_u, s0) would return 
>>> default context of user_xserver_t either.
>> So for using system cronfiles, the getseuserbyname() call needs to be 
>> skilled (since you've already decided on the user - system_u, user.c: 
>> line 87). Not sure about level. Alternatively you can query using root.
> Seems to me we have two choices.  One is to change cron to default to 
> "root" when there is no username or to add system_u to the seusers file.
Well, on second thought querying root is not going to get you system_u 
in any way...
I think the seuser  query just needs to be skipped if you've decided to 
use system_u.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Why cron doesn't work in strict policy

[Stephen Smalley]

On Tue, 2006-02-07 at 09:34 -0500, Daniel J Walsh wrote:
> Ivan Gyurdiev wrote:
> >
> >>
> >> cron ---> getseuserbyname(system_u)
> >> selinux <--- (user_u, s0)
> >> cron ---> get_default_context_with_level(user_u, s0)
> >> selinux <--- (user_u:user_r:user_xserver_t) (????)
> >> cron ---> security_compute_av(user_u:user_r:user_xserver_t, 
> >> system_u:object_r:system_cron_spool_t)
> >> selinux <-- not allowed
> >>
> >> The problem comes from system_u being mapped to __default__ in the 
> >> seusers file, although I have no idea why (user_u, s0) would return 
> >> default context of user_xserver_t either.
> > So for using system cronfiles, the getseuserbyname() call needs to be 
> > skilled (since you've already decided on the user - system_u, user.c: 
> > line 87). Not sure about level. Alternatively you can query using root.
> Seems to me we have two choices.  One is to change cron to default to 
> "root" when there is no username or to add system_u to the seusers file.
> 
> Right now cron has the following code in it.
> 
>     if (get_security_context(pw == NULL ? "system_u" : uname,
>                  crontab_fd,
>                  &u->scontext, tabname) != 0) {
>         free_user(u);
>         u = NULL;
>         goto done;
>     }
>    
> 
> 
> get_security_context()
> ...
>     if (getseuserbyname(name, &seuser, &level) == 0) {
>         retval=get_default_context_with_level(seuser, level, NULL, 
> &scontext);
>         free(seuser);
>         free(level);
>         if (retval) {
> ...
> 
> Which causes cron jobs on strict policy and I would guess MLS to run at 
> user_u since system_u is not defined and would run at level s0. 

We should add system_u to seusers.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Why cron doesn't work in strict policy

[Daniel J Walsh]

Stephen Smalley wrote:
> On Tue, 2006-02-07 at 09:34 -0500, Daniel J Walsh wrote:
>   
>> Ivan Gyurdiev wrote:
>>     
>>>> cron ---> getseuserbyname(system_u)
>>>> selinux <--- (user_u, s0)
>>>> cron ---> get_default_context_with_level(user_u, s0)
>>>> selinux <--- (user_u:user_r:user_xserver_t) (????)
>>>> cron ---> security_compute_av(user_u:user_r:user_xserver_t, 
>>>> system_u:object_r:system_cron_spool_t)
>>>> selinux <-- not allowed
>>>>
>>>> The problem comes from system_u being mapped to __default__ in the 
>>>> seusers file, although I have no idea why (user_u, s0) would return 
>>>> default context of user_xserver_t either.
>>>>         
>>> So for using system cronfiles, the getseuserbyname() call needs to be 
>>> skilled (since you've already decided on the user - system_u, user.c: 
>>> line 87). Not sure about level. Alternatively you can query using root.
>>>       
>> Seems to me we have two choices.  One is to change cron to default to 
>> "root" when there is no username or to add system_u to the seusers file.
>>
>> Right now cron has the following code in it.
>>
>>     if (get_security_context(pw == NULL ? "system_u" : uname,
>>                  crontab_fd,
>>                  &u->scontext, tabname) != 0) {
>>         free_user(u);
>>         u = NULL;
>>         goto done;
>>     }
>>    
>>
>>
>> get_security_context()
>> ...
>>     if (getseuserbyname(name, &seuser, &level) == 0) {
>>         retval=get_default_context_with_level(seuser, level, NULL, 
>> &scontext);
>>         free(seuser);
>>         free(level);
>>         if (retval) {
>> ...
>>
>> Which causes cron jobs on strict policy and I would guess MLS to run at 
>> user_u since system_u is not defined and would run at level s0. 
>>     
>
> We should add system_u to seusers.
>
>   
system_u:system_u:s0-s0:c0.c255


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Why cron doesn't work in strict policy

[Ivan Gyurdiev]

>> Which causes cron jobs on strict policy and I would guess MLS to run at 
>> user_u since system_u is not defined and would run at level s0. 
>>     
>
> We should add system_u to seusers.
>   
Why? There's no such Linux user...
This will cause problems with genhomedircon.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Why cron doesn't work in strict policy

[Stephen Smalley]

On Tue, 2006-02-07 at 09:42 -0500, Ivan Gyurdiev wrote:
> >> Which causes cron jobs on strict policy and I would guess MLS to run at 
> >> user_u since system_u is not defined and would run at level s0. 
> >>     
> >
> > We should add system_u to seusers.
> >   
> Why? There's no such Linux user...
> This will cause problems with genhomedircon.

What kind of problem?  Other alternative is to have crond skip the
getseuserbyname() lookup if dealing with a system cron job (indicated by
use of system_u), which just means a special cased check in the crond
code.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Why cron doesn't work in strict policy

[Ivan Gyurdiev]

> What kind of problem? 
The user doesn't exist, while genhomedircon() will do a passwd check on 
it, and print out warnings.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Why cron doesn't work in strict policy

[Daniel J Walsh]

Ivan Gyurdiev wrote:
>
>> What kind of problem? 
> The user doesn't exist, while genhomedircon() will do a passwd check 
> on it, and print out warnings.
>
You could change genhomedircon to ignore it as it does for default and 
user_u now.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.