process context

process context

[Carlos Anisio Monteiro]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

Hi.

The system have many process running in the following context: 
system_u:system_r:kernel_t (see example below).

 PID CONTEXT                                  COMMAND
    1 system_u:system_r:kernel_t               init [2]
    2 system_u:system_r:kernel_t               [ksoftirqd/0]
    3 system_u:system_r:kernel_t               [events/0]
    7 system_u:system_r:kernel_t               [kswapd0]
    8 system_u:system_r:kernel_t               [aio/0]
    9 system_u:system_r:kernel_t               [kseriod]
   33 system_u:system_r:kernel_t               [kjournald]
  250 system_u:system_r:kernel_t               /sbin/syslogd
  253 system_u:system_r:kernel_t               /sbin/klogd
  262 system_u:system_r:kernel_t               /usr/sbin/inetd
  346 system_u:system_r:kernel_t               sendmail: MTA: accepting 
connections
  373 system_u:system_r:kernel_t               /usr/sbin/cron
  378 system_u:system_r:kernel_t               /sbin/getty 38400 tty2
  379 system_u:system_r:kernel_t               /sbin/getty 38400 tty3

This is happen in the time of boot.

Is this correct? Any process, p.ex. init, syslogd, klogd, shouldn't they 
running in the proper context?
P.ex.:
init - system_u:system_r:init_t
klogd - system_u:system_r:klogd_t
cron - system_u:system_r:cron_t

If yes. How I resolve ???

thanks.

-- 
Carlos Anisio Monteiro  <monteiro@ipen.br>
IPEN/CNEN-SP
Sao Paulo - Brasil


[-- Attachment #2: Type: text/html, Size: 3172 bytes --]

Re: process context

[Russell Coker]

On Fri, 17 Oct 2003 04:57, Carlos Anisio Monteiro wrote:
> The system have many process running in the following context:
> system_u:system_r:kernel_t (see example below).
>
>  PID CONTEXT                                  COMMAND
>   250 system_u:system_r:kernel_t               /sbin/syslogd
>   253 system_u:system_r:kernel_t               /sbin/klogd
>   262 system_u:system_r:kernel_t               /usr/sbin/inetd
>   346 system_u:system_r:kernel_t               sendmail: MTA: accepting
> connections
>   373 system_u:system_r:kernel_t               /usr/sbin/cron
>   378 system_u:system_r:kernel_t               /sbin/getty 38400 tty2
>   379 system_u:system_r:kernel_t               /sbin/getty 38400 tty3
>
> This is happen in the time of boot.

I guess that at boot time the init process (usually /sbin/init) was not 
labeled with init_exec_t, that caused init to be run in kernel_t.

root@lyta:/etc/selinux# grep kernel_t.*process.transition policy.conf
allow kernel_t init_t:process transition;
allow kernel_t insmod_t:process transition;
allow kernel_t hotplug_t:process transition;
allow { initrc_t kernel_t } insmod_t:process transition;
root@lyta:/etc/selinux#

As you can see above kernel_t can only transition to init_t, insmod_t, and 
hotplug_t in a default policy.  So therefore when you have init running in 
kernel_t every process that init runs (either directly or indirectly) apart 
from modprobe and hotplug will be in kernel_t.

If you label init correctly and run "telinit u" then init should re-exec 
itself in the correct context.  If you then run "killall -9 getty" the getty 
processes should be restarted in the correct context.  After getting getty 
running in the correct context you should be able to login at the console and 
then use run_init to restart the daemons and thus get them all running in the 
right context without rebooting.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: process context

[Russell Coker]

On Fri, 17 Oct 2003 13:27, Russell Coker wrote:
> I guess that at boot time the init process (usually /sbin/init) was not

Sorry, I meant to say "the executable for the init process".

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: process context

[kamal]

Russell Coker wrote:

>I guess that at boot time the init process (usually /sbin/init) was not 
>labeled with init_exec_t, that caused init to be run in kernel_t.
>  
>
But why does this happen? I also had the same problem, and because getty 
process is not labeled properly, login fails to get default context.

Output of "ls --context /sbin/init" is:
-rwxr-xr-x  root     root     system_u:object_r:init_exec_t    /sbin/init



--
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: process context

[Russell Coker]

On Fri, 17 Oct 2003 20:36, kamal wrote:
> Russell Coker wrote:
> >I guess that at boot time the init process (usually /sbin/init) was not
> >labeled with init_exec_t, that caused init to be run in kernel_t.
>
> But why does this happen? I also had the same problem, and because getty
> process is not labeled properly, login fails to get default context.

The most likely cause of /sbin/init having the wrong type is that it was never 
labeled correctly.  The seond most likely cause is that you copied over a 
newer version without relabeling afterwards.

> Output of "ls --context /sbin/init" is:
> -rwxr-xr-x  root     root     system_u:object_r:init_exec_t    /sbin/init

That's the correct value.  So "telinit u" should result in it getting the 
right context.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: process context

[Stephen Smalley]

On Fri, 2003-10-17 at 06:36, kamal wrote:
> But why does this happen? I also had the same problem, and because getty 
> process is not labeled properly, login fails to get default context.
> 
> Output of "ls --context /sbin/init" is:
> -rwxr-xr-x  root     root     system_u:object_r:init_exec_t    /sbin/init

As with the other poster, your problem may be that you aren't loading
the policy prior to executing /sbin/init, or you are loading the policy
via /sbin/init but failing to re-execute it.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: process context

[Stephen Smalley]

On Thu, 2003-10-16 at 14:57, Carlos Anisio Monteiro wrote:
> Hi.
> 
> The system have many process running in the following context:
> system_u:system_r:kernel_t (see example below).
<snip>
> 
> This is happen in the time of boot.
> 
> Is this correct? Any process, p.ex. init, syslogd, klogd, shouldn't
> they running in the proper context?
> P.ex.: 
> init - system_u:system_r:init_t
> klogd - system_u:system_r:klogd_t
> cron - system_u:system_r:cron_t
> 
> If yes. How I resolve ???

The possible scenarios are:
1) You never labeled /sbin/init with system_u:object_r:init_exec_t.
Based on your prior email, you have labeled /sbin/init, so this is not
the cause.

2) You labeled /sbin/init initially, but you are running prelink on your
system and do not have the patched prelink program, so prelink is
cheerfully unlinking it and re-creating it with the default type,
causing it to fall back into sbin_t.  You can check for this by doing a
'ls --context /sbin/init' again.  Dan Walsh has a patched prelink
program that preserves security contexts available from his site,
ftp://people.redhat.com/dwalsh/SELinux.  prelink is enabled by default
in Fedora Core.

3) /sbin/init is labeled correctly, but the policy is not loaded prior
to starting it, so the domain transition rule isn't defined when the
execution occurs.  This would happen if you failed to load the policy
from an initrd prior to execution of /sbin/init, or if you are trying to
perform the initial policy load via /sbin/init itself without
re-exec'ing it after performing the load.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: process context

[Carlos Anisio Monteiro]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

Stephen Smalley wrote:

>On Thu, 2003-10-16 at 14:57, Carlos Anisio Monteiro wrote:
>  
>
>>Hi.
>>
>>The system have many process running in the following context:
>>system_u:system_r:kernel_t (see example below).
>>    
>>
><snip>
>  
>
>>This is happen in the time of boot.
>>
>>Is this correct? Any process, p.ex. init, syslogd, klogd, shouldn't
>>they running in the proper context?
>>P.ex.: 
>>init - system_u:system_r:init_t
>>klogd - system_u:system_r:klogd_t
>>cron - system_u:system_r:cron_t
>>
>>If yes. How I resolve ???
>>    
>>
>
>The possible scenarios are:
>1) You never labeled /sbin/init with system_u:object_r:init_exec_t.
>Based on your prior email, you have labeled /sbin/init, so this is not
>the cause.
>
>2) You labeled /sbin/init initially, but you are running prelink on your
>system and do not have the patched prelink program, so prelink is
>cheerfully unlinking it and re-creating it with the default type,
>causing it to fall back into sbin_t.  You can check for this by doing a
>'ls --context /sbin/init' again.  Dan Walsh has a patched prelink
>program that preserves security contexts available from his site,
>ftp://people.redhat.com/dwalsh/SELinux.  prelink is enabled by default
>in Fedora Core.
>
>3) /sbin/init is labeled correctly, but the policy is not loaded prior
>to starting it, so the domain transition rule isn't defined when the
>execution occurs.  This would happen if you failed to load the policy
>from an initrd prior to execution of /sbin/init, or if you are trying to
>perform the initial policy load via /sbin/init itself without
>re-exec'ing it after performing the load.
>
>  
>
I loaded the policy in the initrd image and the boot process and the 
contexts are fine. The policies must be loaded prior to init process.
*I am much obliged to you*.

However, alway that I change one policy I have to update the policies in 
the initrd image. Or, can I load the minimum of policies in the initrd 
image  and the remainder as script in the /etc/init.d directory? So, the 
update to policies in initrd image should be very little.

Again, thanks! Thanks!

-- 
Carlos Anisio Monteiro  <monteiro@ipen.br>
IPEN/CNEN-SP
Sao Paulo - Brasil



[-- Attachment #2: Type: text/html, Size: 2814 bytes --]

Re: process context

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]

Carlos Anisio Monteiro wrote:

> Stephen Smalley wrote:
>
>>On Thu, 2003-10-16 at 14:57, Carlos Anisio Monteiro wrote:
>>  
>>
>>>Hi.
>>>
>>>The system have many process running in the following context:
>>>system_u:system_r:kernel_t (see example below).
>>>    
>>>
>><snip>
>>  
>>
>>>This is happen in the time of boot.
>>>
>>>Is this correct? Any process, p.ex. init, syslogd, klogd, shouldn't
>>>they running in the proper context?
>>>P.ex.: 
>>>init - system_u:system_r:init_t
>>>klogd - system_u:system_r:klogd_t
>>>cron - system_u:system_r:cron_t
>>>
>>>If yes. How I resolve ???
>>>    
>>>
>>
>>The possible scenarios are:
>>1) You never labeled /sbin/init with system_u:object_r:init_exec_t.
>>Based on your prior email, you have labeled /sbin/init, so this is not
>>the cause.
>>
>>2) You labeled /sbin/init initially, but you are running prelink on your
>>system and do not have the patched prelink program, so prelink is
>>cheerfully unlinking it and re-creating it with the default type,
>>causing it to fall back into sbin_t.  You can check for this by doing a
>>'ls --context /sbin/init' again.  Dan Walsh has a patched prelink
>>program that preserves security contexts available from his site,
>>ftp://people.redhat.com/dwalsh/SELinux.  prelink is enabled by default
>>in Fedora Core.
>>
>>3) /sbin/init is labeled correctly, but the policy is not loaded prior
>>to starting it, so the domain transition rule isn't defined when the
>>execution occurs.  This would happen if you failed to load the policy
>>from an initrd prior to execution of /sbin/init, or if you are trying to
>>perform the initial policy load via /sbin/init itself without
>>re-exec'ing it after performing the load.
>>
>>  
>>
> I loaded the policy in the initrd image and the boot process and the 
> contexts are fine. The policies must be loaded prior to init process.
> *I am much obliged to you*.
>
> However, alway that I change one policy I have to update the policies 
> in the initrd image. Or, can I load the minimum of policies in the 
> initrd image  and the remainder as script in the /etc/init.d 
> directory? So, the update to policies in initrd image should be very 
> little.
>
> Again, thanks! Thanks!

Currently that is what we are suggesting.  Modify mkinitrd with minimal 
policy and then have the initscripts load the on disk policy as early as 
possible.   We are working to the point where init itself will load 
policy and modification of the initrd will go away.

Dan

>
>-- 
>Carlos Anisio Monteiro  <monteiro@ipen.br>
>IPEN/CNEN-SP
>Sao Paulo - Brasil
>  
>
>

[-- Attachment #2: Type: text/html, Size: 3454 bytes --]

Re: process context

[Russell Coker]

On Tue, 21 Oct 2003 00:01, Daniel J Walsh wrote:
> Currently that is what we are suggesting.  Modify mkinitrd with minimal
> policy and then have the initscripts load the on disk policy as early as
> possible.   We are working to the point where init itself will load
> policy and modification of the initrd will go away.

Unless of course we decide to go with a modified init, which means that we 
don't need policy in the initrd.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



--
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.