login messages

login messages

[Kratzer, James R.]

When I login as my user, I get the following messages.   Is this normal and
can someone explain what they mean?  When I log in as root, I do not get
these messages.

Your default context is jamesk:user_r:user_t
Keymap 0: Permission denied
Keymap 1: Permission denied
Keymap 2: Permission denied
KDSKBENT: Operation not permitted
loadkeys: could not deallocate keymap 3


When I then try to switch to the sysadm role from the user role, I get the
following message.  In my policy "user" file, I have jamesk set for {
staff_r sysadm_r } roles.  Why can't I switch?

# newrole -r sysadm_r
jamesk:sysadm_r:sysadm_t is not a valid context

--
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: login messages

[Stephen Smalley]

On Mon, 2003-10-06 at 10:35, Kratzer, James R. wrote:
> When I login as my user, I get the following messages.   Is this normal and
> can someone explain what they mean?  When I log in as root, I do not get
> these messages.
> 
> Your default context is jamesk:user_r:user_t
> Keymap 0: Permission denied
> Keymap 1: Permission denied
> Keymap 2: Permission denied
> KDSKBENT: Operation not permitted
> loadkeys: could not deallocate keymap 3

Yes, I see this as well.  SELinux checks the CAP_SYS_TTY_CONFIG
capability for the KDSKBENT and KDSKBSENT ioctls to prevent unprivileged
processes from changing the keyboard mapping.  See
http://marc.theaimsgroup.com/?l=selinux&m=103122430232003&w=2.
So the attempt to run loadkeys is going to fail; it needs to be called
from a more trusted context to set up the authorized mappings.

> When I then try to switch to the sysadm role from the user role, I get the
> following message.  In my policy "user" file, I have jamesk set for {
> staff_r sysadm_r } roles.  Why can't I switch?
> 
> # newrole -r sysadm_r
> jamesk:sysadm_r:sysadm_t is not a valid context

The fact that your default context was jamesk:user_r:user_t shows that
the actual policy loaded into your kernel is not what you describe,
since you don't even list user_r above.  So you likely changed your
policy and forgot to reload it, or you changed your policy but didn't
rebuild the initrd and have subsequently rebooted, thus loading the old
policy from the initrd.

Russell has suggested loading only a minimal policy from the initrd and
then loading a full policy from the disk via a change to
/etc/rc.d/rc.sysinit to mount /selinux and then run load_policy on the
policy file on the disk.  This allows you to make changes to the policy
that aren't relevant to the initialization prior to rc.sysinit without
needing to rebuild your initrd each time.

-- 
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: login messages

[Tom]

On Mon, Oct 06, 2003 at 10:35:39AM -0400, Kratzer, James R. wrote:
> When I then try to switch to the sysadm role from the user role, I get the
> following message.  In my policy "user" file, I have jamesk set for {
> staff_r sysadm_r } roles.  Why can't I switch?
> 
> # newrole -r sysadm_r
> jamesk:sysadm_r:sysadm_t is not a valid context

Have you rebuild and reloaded the policy after you made this change?
Any changes you make to SELinux policy will not take effect until that
policy is compiled and loaded into the kernel.


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

Re: login messages

[Russell Coker]

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

On Tue, 7 Oct 2003 02:19, Stephen Smalley wrote:
> > Your default context is jamesk:user_r:user_t
> > Keymap 0: Permission denied
> > Keymap 1: Permission denied
> > Keymap 2: Permission denied
> > KDSKBENT: Operation not permitted
> > loadkeys: could not deallocate keymap 3
>
> Yes, I see this as well.  SELinux checks the CAP_SYS_TTY_CONFIG
> capability for the KDSKBENT and KDSKBSENT ioctls to prevent unprivileged
> processes from changing the keyboard mapping.  See
> http://marc.theaimsgroup.com/?l=selinux&m=103122430232003&w=2.
> So the attempt to run loadkeys is going to fail; it needs to be called
> from a more trusted context to set up the authorized mappings.

This was an awdward one that I found too difficult the first time I tried to 
do it.

It did not give any audit messages because by Unix permissions the capability 
was denied so it didn't even reach SE Linux.  It seems that in Red Hat 
loadkeys is run from /bin/unicode_start in the context of the user (from
/etc/profile.d/lang.*).  So I wrote a little SUID root helper program (to 
regain CAP_SYS_TTY_CONFIG) which I copied to /bin/unicode_start (the original 
file was renamed to /bin/unicode_start.orig).  I made /bin/unicode_start be a 
SUID program to gain the Unix permissions and also labeled it as type 
loadkeys_exec_t which causes a transition to user_loadkeys_t, user_loadkeys_t 
has SETUID and SYS_TTY_CONFIG capabilities.  I also added 
"loadkeys_domain($1)" to macros/user_macros.te .

This makes the error messages go away, but I am not certain it's the right 
thing to do.  If someone could advise me on how to test that functionality I 
would really appreciate it.  At the moment I am not certain that what I am 
doing even gives full functionality as desired.

The user_loadkeys_t domain is probably not appropriately named (I named it 
before I really understood what's going on), I may rename it before releasing 
the relevant code.

I am not sure whether a separate user_loadkeys_t domain is needed for each 
user role or whether I should just have it always use loadkeys_t (as is done 
for ping and tcpdump).

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

[-- Attachment #2: unicode_start.c --]
[-- Type: text/x-csrc, Size: 301 bytes --]

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

const char * const real_prog = "/bin/unicode_start.orig";

int main(int argc, char **argv, char **envp)
{
  int rc;
  setreuid(0, 0);
  rc = execve(real_prog, argv, envp);
  fprintf(stderr, "Can't execute %s\n", real_prog);
  return 1;
}

[-- Attachment #3: loadkeys.fc --]
[-- Type: text/plain, Size: 67 bytes --]

# loadkeys
/bin/unicode_start				system_u:object_r:loadkeys_exec_t

[-- Attachment #4: loadkeys.te --]
[-- Type: text/plain, Size: 348 bytes --]

#DESC Su - Run shells with substitute user and group
#
# Domains for the su program.
#
# Depends: login.te

#
# loadkeys_exec_t is the type of the su executable.
#
type loadkeys_exec_t, file_type, sysadmfile, exec_type;

can_exec(initrc_t, loadkeys_exec_t)

# Everything else is in the loadkeys_domain macro in
# macros/program/loadkeys_macros.te.

[-- Attachment #5: loadkeys_macros.te --]
[-- Type: text/plain, Size: 1546 bytes --]

#
# Macros for loadkeys
#

#
# Author:  Russell Coker <russell@coker.com.au>
#

#
# loadkeys_domain(domain_prefix)
#
# Define a derived domain for the loadkeys program when executed
# by a user domain.
#
# The type declaration for the executable type for this program is
# provided separately in domains/program/loadkeys.te. 
#
undefine(`loadkeys_domain')
ifdef(`loadkeys.te', `
define(`loadkeys_domain', `
# do not define this domain for sysadm
ifelse(`$1', `sysadm', `', `
# Derived domain based on the calling user domain and the program.
type $1_loadkeys_t, domain;

# Transition from the user domain to this domain.
domain_auto_trans($1_t, loadkeys_exec_t, $1_loadkeys_t)

uses_shlib($1_loadkeys_t)
dontaudit $1_loadkeys_t proc_t:dir search;
allow $1_loadkeys_t proc_t:file { getattr read };
allow $1_loadkeys_t self:process { fork sigchld };

allow $1_loadkeys_t self:fifo_file rw_file_perms;
allow $1_loadkeys_t bin_t:dir search;
allow $1_loadkeys_t bin_t:lnk_file read;
can_exec($1_loadkeys_t, { shell_exec_t bin_t })

read_locale($1_loadkeys_t)

dontaudit $1_loadkeys_t etc_runtime_t:file { getattr read };

# Use capabilities.
allow $1_loadkeys_t self:capability { setuid sys_tty_config };

allow $1_loadkeys_t local_login_t:fd use;
allow $1_loadkeys_t devtty_t:chr_file rw_file_perms;

# The user role is authorized for this domain.
role $1_r types $1_loadkeys_t;

# Write to the user domain tty.
allow $1_loadkeys_t $1_tty_device_t:chr_file rw_file_perms;

')dnl end ifelse sysadm

')dnl end loadkeys_domain

')dnl end ifdef loadkeys

Re: login messages

[Stephen Smalley]

On Tue, 2003-10-07 at 01:32, Russell Coker wrote:
> It did not give any audit messages because by Unix permissions the capability 
> was denied so it didn't even reach SE Linux.  

Right, this is because we perform a full capable(CAP_SYS_TTY_CONFIG)
call in selinux_file_ioctl rather than only performing the SELinux
capability permission check via task_has_capability.  We could change
this so that you only need the SELinux permission and not the Linux
capability.  That avoids changing the Linux permissions model.

> It seems that in Red Hat 
> loadkeys is run from /bin/unicode_start in the context of the user (from
> /etc/profile.d/lang.*).  So I wrote a little SUID root helper program (to 
> regain CAP_SYS_TTY_CONFIG) which I copied to /bin/unicode_start (the original 
> file was renamed to /bin/unicode_start.orig).  I made /bin/unicode_start be a 
> SUID program to gain the Unix permissions and also labeled it as type 
> loadkeys_exec_t which causes a transition to user_loadkeys_t, user_loadkeys_t 
> has SETUID and SYS_TTY_CONFIG capabilities.  I also added 
> "loadkeys_domain($1)" to macros/user_macros.te .

I don't think that this helps, unless you are carefully limiting the
types that can be read by user_loadkeys_t, since the user can still
specify a font and umap as arguments to unicode_start and thus specify
an arbitrary map.  Even if you use the policy to limit it to certain
system types, it isn't clear that it is safe to allow the user to select
any system-installed mapping.  The safest approach would be to have
getty or login perform the loading, and to load authorized mappings that
aren't subject to configuration by ordinary users.

-- 
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: login messages

[Russell Coker]

On Tue, 7 Oct 2003 23:51, Stephen Smalley wrote:
> I don't think that this helps, unless you are carefully limiting the
> types that can be read by user_loadkeys_t, since the user can still
> specify a font and umap as arguments to unicode_start and thus specify
> an arbitrary map.  Even if you use the policy to limit it to certain
> system types, it isn't clear that it is safe to allow the user to select
> any system-installed mapping.  The safest approach would be to have
> getty or login perform the loading, and to load authorized mappings that
> aren't subject to configuration by ordinary users.

Currently the consensus of opinion within Red Hat is to have the system 
installed mappings be audited to avoid any problems regarding the loading of 
bad mappings.  Then we just allow loading any system mappings by the user at 
any time.  Having a mapping be bad enough to cause problems seems to require 
a fairly gross error in the mapping.  Allowing the user to choose between 
different system mappings seems to be a big enough benefit to outweigh the 
tiny risk of immense gross errors in mappings.

Also I think I'll just make it loadkeys_t instead of having a number of 
user_loadkeys_t domains.


PS  Before someone asks, yes this is important.  Having console access does 
NOT mean that you can break the security of the machine in any trivial way.  
Think about "Internet terminal" devices that are physically secured as well 
as a Coke vending machine.

-- 
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: login messages

[Stephen Smalley]

On Tue, 2003-10-07 at 11:43, Russell Coker wrote:
> Currently the consensus of opinion within Red Hat is to have the system 
> installed mappings be audited to avoid any problems regarding the loading of 
> bad mappings.  Then we just allow loading any system mappings by the user at 
> any time.  Having a mapping be bad enough to cause problems seems to require 
> a fairly gross error in the mapping.  Allowing the user to choose between 
> different system mappings seems to be a big enough benefit to outweigh the 
> tiny risk of immense gross errors in mappings.
> 
> Also I think I'll just make it loadkeys_t instead of having a number of 
> user_loadkeys_t domains.

So, what's the resolution on the capable() check being performed by the
SELinux module?  Should it be reduced from a full capable() check (i.e.
Linux capability and SELinux permission check) to just a SELinux
capability permission check, to avoid changing the Linux permissions
model and the need for a setuid program?

-- 
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: login messages

[Russell Coker]

On Fri, 10 Oct 2003 05:39, Stephen Smalley wrote:
> > Also I think I'll just make it loadkeys_t instead of having a number of
> > user_loadkeys_t domains.
>
> So, what's the resolution on the capable() check being performed by the
> SELinux module?  Should it be reduced from a full capable() check (i.e.
> Linux capability and SELinux permission check) to just a SELinux
> capability permission check, to avoid changing the Linux permissions
> model and the need for a setuid program?

I think that makes sense at the moment.

However I think that the kernel people should consider making this capability 
a requirement for non-SE kernels.  James, what do you think?

-- 
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: login messages

[James Morris]

On Fri, 10 Oct 2003, Russell Coker wrote:

> On Fri, 10 Oct 2003 05:39, Stephen Smalley wrote:
> > > Also I think I'll just make it loadkeys_t instead of having a number of
> > > user_loadkeys_t domains.
> >
> > So, what's the resolution on the capable() check being performed by the
> > SELinux module?  Should it be reduced from a full capable() check (i.e.
> > Linux capability and SELinux permission check) to just a SELinux
> > capability permission check, to avoid changing the Linux permissions
> > model and the need for a setuid program?
> 
> I think that makes sense at the moment.
> 
> However I think that the kernel people should consider making this capability 
> a requirement for non-SE kernels.  James, what do you think?
> 

I don't think that further restricting this for the standard kernel is
necessary, although feel free to propose the change on lkml if you feel
strongly about it.

I also agree that it is probably better to move from a capability check to
an SELinux permission.


- James
-- 
James Morris
<jmorris@redhat.com>



--
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: login messages

[Kratzer, James R.]

Yes, I have performed a "make load" from the policy direcotry to rebuild
and load the policy.  I have also rebuilt the initrd file using mkinitrd.  I
still cannot switch roles.  What else can I look at?

-----Original Message-----
From: Tom [mailto:tom@lemuria.org]
Sent: Monday, October 06, 2003 1:56 PM
To: Kratzer, James R.
Cc: SELinux (E-mail)
Subject: Re: login messages


On Mon, Oct 06, 2003 at 10:35:39AM -0400, Kratzer, James R. wrote:
> When I then try to switch to the sysadm role from the user role, I get the
> following message.  In my policy "user" file, I have jamesk set for {
> staff_r sysadm_r } roles.  Why can't I switch?
> 
> # newrole -r sysadm_r
> jamesk:sysadm_r:sysadm_t is not a valid context

Have you rebuild and reloaded the policy after you made this change?
Any changes you make to SELinux policy will not take effect until that
policy is compiled and loaded into the kernel.


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