Problems with /dev/tty on reboot.

Problems with /dev/tty on reboot.

[Daniel J Walsh]

How should we handle the situation where contexts end up in the wrong 
contexts because of crashes or reboots.

Currently if you login to a box as user_t, and then the system crashes 
or you reboot the /dev/tty has the wrong context on it, so if the next 
user that attempts to login has staff_t he will not be able to gain 
access to the device.  I have put a
setfiles file_context /dev/tty in my rc scripts as a stop gap, but that 
is not a clean solution.  Also this can probably happen to other files 
that have their contexts changed by running processes.  Ideas on how to 
solve this problem??

Dan


--
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: Problems with /dev/tty on reboot.

[Stephen Smalley]

On Wed, 2003-11-26 at 08:48, Daniel J Walsh wrote:
> How should we handle the situation where contexts end up in the wrong 
> contexts because of crashes or reboots.
> 
> Currently if you login to a box as user_t, and then the system crashes 
> or you reboot the /dev/tty has the wrong context on it, so if the next 
> user that attempts to login has staff_t he will not be able to gain 
> access to the device.  I have put a
> setfiles file_context /dev/tty in my rc scripts as a stop gap, but that 
> is not a clean solution.  Also this can probably happen to other files 
> that have their contexts changed by running processes.  Ideas on how to 
> solve this problem??

The same issue should exist for the uid/gid on the tty; I would expect
that getty resets the owner on the tty to avoid this problem, so you
could likewise have getty reset the label.  In the past, we worked
around the problem by providing broader type_change rules in the policy,
e.g.
	type_change staff_t ttyfile:chr_file staff_tty_device_t;

I'm not sure why these were removed.  In fact, I see the general form of
this rule in policy/macros/user_macros.te, as:
	type_change $1_t ttyfile:chr_file $1_tty_device_t;
but it is within an ifdef(`dpkg.te') block for some reason.

Note:  type_change rules just indicate what new type to use when
relabeling an existing file with a given type for a process with a given
domain.  Programs like login use the security_compute_relabel()
interface to obtain the new context for the tty, and this new context is
computed based on the type_change rules.

-- 
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: Problems with /dev/tty on reboot.

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Wed, 2003-11-26 at 08:48, Daniel J Walsh wrote:
>  
>
>>How should we handle the situation where contexts end up in the wrong 
>>contexts because of crashes or reboots.
>>
>>Currently if you login to a box as user_t, and then the system crashes 
>>or you reboot the /dev/tty has the wrong context on it, so if the next 
>>user that attempts to login has staff_t he will not be able to gain 
>>access to the device.  I have put a
>>setfiles file_context /dev/tty in my rc scripts as a stop gap, but that 
>>is not a clean solution.  Also this can probably happen to other files 
>>that have their contexts changed by running processes.  Ideas on how to 
>>solve this problem??
>>    
>>
>
>The same issue should exist for the uid/gid on the tty; I would expect
>that getty resets the owner on the tty to avoid this problem, so you
>could likewise have getty reset the label.  In the past, we worked
>around the problem by providing broader type_change rules in the policy,
>e.g.
>	type_change staff_t ttyfile:chr_file staff_tty_device_t;
>
>I'm not sure why these were removed.  In fact, I see the general form of
>this rule in policy/macros/user_macros.te, as:
>	type_change $1_t ttyfile:chr_file $1_tty_device_t;
>but it is within an ifdef(`dpkg.te') block for some reason.
>
>Note:  type_change rules just indicate what new type to use when
>relabeling an existing file with a given type for a process with a given
>domain.  Programs like login use the security_compute_relabel()
>interface to obtain the new context for the tty, and this new context is
>computed based on the type_change rules.
>  
>

Ok, moving the ifdef(`dpkg.te') rule allowed login to relabel the tty 
and me to login, but should we still make the change to getty to relabel 
the tty?  If yes, how should getty determine what context to set the tty 
too?  Do we need to add something to default_contexts or is there 
another way to determine this?

Dan

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

Re: Problems with /dev/tty on reboot.

[Stephen Smalley]

On Wed, 2003-11-26 at 09:50, Daniel J Walsh wrote:
> Ok, moving the ifdef(`dpkg.te') rule allowed login to relabel the tty
> and me to login, but should we still make the change to getty to
> relabel the tty?  If yes, how should getty determine what context to
> set the tty too?  Do we need to add something to default_contexts or
> is there another way to determine this?

If getty already resets the ownership, then it makes sense to also patch
it to reset the context.  It can pull a single context from a config
file like run_init does, or this could be the time to create that
libselinux function that returns the matching context from the file
contexts configuration for a given pathname...

-- 
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: Problems with /dev/tty on reboot.

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Wed, 2003-11-26 at 09:50, Daniel J Walsh wrote:
>  
>
>>Ok, moving the ifdef(`dpkg.te') rule allowed login to relabel the tty
>>and me to login, but should we still make the change to getty to
>>relabel the tty?  If yes, how should getty determine what context to
>>set the tty too?  Do we need to add something to default_contexts or
>>is there another way to determine this?
>>    
>>
>
>If getty already resets the ownership, then it makes sense to also patch
>it to reset the context.  It can pull a single context from a config
>file like run_init does, or this could be the time to create that
>libselinux function that returns the matching context from the file
>contexts configuration for a given pathname...
>  
>
Well we need this function anyways if rpm is going to set default 
contexts for files...
Dan

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

Re: Problems with /dev/tty on reboot.

[Tom]

On Wed, Nov 26, 2003 at 08:48:27AM -0500, Daniel J Walsh wrote:
> is not a clean solution.  Also this can probably happen to other files 
> that have their contexts changed by running processes.  Ideas on how to 
> solve this problem??

Your solution doesn't sound too bad.

Have a config file, say /etc/selinux/required_file_contexts and call
setfiles from an init script very early.


-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

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