* process context
@ 2003-10-16 18:57 Carlos Anisio Monteiro
2003-10-17 3:27 ` Russell Coker
2003-10-17 12:03 ` Stephen Smalley
0 siblings, 2 replies; 10+ messages in thread
From: Carlos Anisio Monteiro @ 2003-10-16 18:57 UTC (permalink / raw)
To: selinux
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: process context
2003-10-16 18:57 process context Carlos Anisio Monteiro
@ 2003-10-17 3:27 ` Russell Coker
2003-10-17 4:17 ` Russell Coker
2003-10-17 10:36 ` kamal
2003-10-17 12:03 ` Stephen Smalley
1 sibling, 2 replies; 10+ messages in thread
From: Russell Coker @ 2003-10-17 3:27 UTC (permalink / raw)
To: Carlos Anisio Monteiro, selinux
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: process context
2003-10-17 3:27 ` Russell Coker
@ 2003-10-17 4:17 ` Russell Coker
2003-10-17 10:36 ` kamal
1 sibling, 0 replies; 10+ messages in thread
From: Russell Coker @ 2003-10-17 4:17 UTC (permalink / raw)
To: Carlos Anisio Monteiro, selinux
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: process context
2003-10-17 3:27 ` Russell Coker
2003-10-17 4:17 ` Russell Coker
@ 2003-10-17 10:36 ` kamal
2003-10-17 11:24 ` Russell Coker
2003-10-17 12:08 ` Stephen Smalley
1 sibling, 2 replies; 10+ messages in thread
From: kamal @ 2003-10-17 10:36 UTC (permalink / raw)
To: selinux
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: process context
2003-10-17 10:36 ` kamal
@ 2003-10-17 11:24 ` Russell Coker
2003-10-17 12:08 ` Stephen Smalley
1 sibling, 0 replies; 10+ messages in thread
From: Russell Coker @ 2003-10-17 11:24 UTC (permalink / raw)
To: kamal, selinux
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: process context
2003-10-16 18:57 process context Carlos Anisio Monteiro
2003-10-17 3:27 ` Russell Coker
@ 2003-10-17 12:03 ` Stephen Smalley
2003-10-20 10:54 ` Carlos Anisio Monteiro
1 sibling, 1 reply; 10+ messages in thread
From: Stephen Smalley @ 2003-10-17 12:03 UTC (permalink / raw)
To: Carlos Anisio Monteiro; +Cc: selinux, Russell Coker
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: process context
2003-10-17 10:36 ` kamal
2003-10-17 11:24 ` Russell Coker
@ 2003-10-17 12:08 ` Stephen Smalley
1 sibling, 0 replies; 10+ messages in thread
From: Stephen Smalley @ 2003-10-17 12:08 UTC (permalink / raw)
To: kamal; +Cc: selinux, Russell Coker
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: process context
2003-10-17 12:03 ` Stephen Smalley
@ 2003-10-20 10:54 ` Carlos Anisio Monteiro
2003-10-20 14:01 ` Daniel J Walsh
0 siblings, 1 reply; 10+ messages in thread
From: Carlos Anisio Monteiro @ 2003-10-20 10:54 UTC (permalink / raw)
To: Stephen Smalley, Russell Coker, Daniel J Walsh, selinux
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: process context
2003-10-20 10:54 ` Carlos Anisio Monteiro
@ 2003-10-20 14:01 ` Daniel J Walsh
2003-10-21 1:07 ` Russell Coker
0 siblings, 1 reply; 10+ messages in thread
From: Daniel J Walsh @ 2003-10-20 14:01 UTC (permalink / raw)
To: Carlos Anisio Monteiro; +Cc: Stephen Smalley, Russell Coker, selinux
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: process context
2003-10-20 14:01 ` Daniel J Walsh
@ 2003-10-21 1:07 ` Russell Coker
0 siblings, 0 replies; 10+ messages in thread
From: Russell Coker @ 2003-10-21 1:07 UTC (permalink / raw)
To: Daniel J Walsh, Carlos Anisio Monteiro; +Cc: Stephen Smalley, selinux
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2003-10-21 1:08 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-10-16 18:57 process context Carlos Anisio Monteiro
2003-10-17 3:27 ` Russell Coker
2003-10-17 4:17 ` Russell Coker
2003-10-17 10:36 ` kamal
2003-10-17 11:24 ` Russell Coker
2003-10-17 12:08 ` Stephen Smalley
2003-10-17 12:03 ` Stephen Smalley
2003-10-20 10:54 ` Carlos Anisio Monteiro
2003-10-20 14:01 ` Daniel J Walsh
2003-10-21 1:07 ` Russell Coker
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.