policy questions and bugs

policy questions and bugs

[Chris Grier]

I have a whole bunch of questions after reading the FAQ and some other
random documents I found for selinux, here they are:

The dpkg and rpm both have apt-get in their domain te files. fixfiles
doesn't like having multiple contexts defined for a single file. This
might be a bug.

Why do dmesg redirections (such as root running dmesg > ~/output) cause
an audit deny? I'm not sure this is a dmesg specific error, I think it
might be a little more general for other redirections too. Here's the
message:

avc:  denied  { write } for  pid=1953 exe=/bin/dmesg path=/root/test
dev=md0 ino=740514 scontext=root:system_r:dmesg_t
tcontext=root:object_r:staff_home_t tclass=file

When running some services, I would like them to run as a non root uid
and gid (ircd and oidentd are the services which I usually do this
with), which I normally do with su. When we do this with selinux
running, we are prompted to enter a role and type (not select from a
list). Is this just a matter of defining a transition to acommodate for
this to happen?

Why do normal users have the option of changing to sysadm? I don't
particularly like this, and I could remove it, but I'm looking for the
reasoning behind the default being like this.

What does this mean: 

inode_doinit_with_dentry:  context_to_sid(system_u:object_r:apt_etc_t)
returned 22 for dev=md0 ino=517610

This is a "new" error (as in, in the last couple hours of getting things
going, I had not seen it). I'm not sure what happened to make this error
start.

Last question for today, when creating my own fc and te files to build
into the policy, is it safe to create them in the policy/src directory,
or will future package updates simply overwrite them and kill all the
stuff I'm writing? How about modifications of existing files in the
policy source directory?

-- 
Chris Grier <grier@uiuc.edu>

--
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: policy questions and bugs

[Colin Walters]

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

On Fri, 2004-05-14 at 23:30, Chris Grier wrote:
> I have a whole bunch of questions after reading the FAQ and some other
> random documents I found for selinux, here they are:
> 
> The dpkg and rpm both have apt-get in their domain te files. fixfiles
> doesn't like having multiple contexts defined for a single file. This
> might be a bug.

Sounds like it, yes.

> Why do dmesg redirections (such as root running dmesg > ~/output) cause
> an audit deny? I'm not sure this is a dmesg specific error, I think it
> might be a little more general for other redirections too. Here's the
> message:
> 
> avc:  denied  { write } for  pid=1953 exe=/bin/dmesg path=/root/test
> dev=md0 ino=740514 scontext=root:system_r:dmesg_t
> tcontext=root:object_r:staff_home_t tclass=file

Under normal operation, the dmesg program doesn't need write access to
your home directory.  Thus using the principle of least privilege, any
write operations will be denied by the SELinux policy.

Allowing arbitrary redirections of program output through the shell, but
denying otherwise is, I believe, not possible using SELinux currently.

> When running some services, I would like them to run as a non root uid
> and gid (ircd and oidentd are the services which I usually do this
> with), which I normally do with su. When we do this with selinux
> running, we are prompted to enter a role and type (not select from a
> list). Is this just a matter of defining a transition to acommodate for
> this to happen?

You run "su" interactively from a root shell?  I'd suggest instead using
init scripts.  

> Why do normal users have the option of changing to sysadm?

That's a Red Hat addition to the policy.

>  I don't
> particularly like this, and I could remove it, but I'm looking for the
> reasoning behind the default being like this.

Basically to make the SELinux experience more like a "normal" Linux
system.

> What does this mean: 
> 
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:apt_etc_t)
> returned 22 for dev=md0 ino=517610

That means that the context system_u:object_r:apt_etc_t is not defined
in the policy.  Probably the apt_etc_t type got deleted somehow from
your policy.

> Last question for today, when creating my own fc and te files to build
> into the policy, is it safe to create them in the policy/src directory,
> or will future package updates simply overwrite them and kill all the
> stuff I'm writing? How about modifications of existing files in the
> policy source directory?

Under Red Hat, they will be moved to .rpmsave, AIUI.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: policy questions and bugs

[Chris Grier]

> ----- Forwarded message from Colin Walters <walters@verbum.org> -----
>                                                                                              
> > When running some services, I would like them to run as a non root uid                     
> > and gid (ircd and oidentd are the services which I usually do this                         
> > with), which I normally do with su. When we do this with selinux                           
> > running, we are prompted to enter a role and type (not select from a                       
> > list). Is this just a matter of defining a transition to acommodate for                    
> > this to happen?                                                                            
>                                                                                              
> You run "su" interactively from a root shell?  I'd suggest instead using                     
> init scripts.                                                                                

No, not interactively. I am trying to use the init scripts. The way it
works is the init function daemon() (from /etc/init.d/functions)
accepts a --user argument to run the daemon as a given user. This
eventually calls su -c to launch the daemon as the approprate user.
The problem is that su prompts, asking to switch roles, and thus this
causes init to hang. Which is bad.

I've tried editing /etc/pam.d/su to remove the "multiple" keyword as
is indicated in the FAQ, but this does nothing to resolve the issue..

> > Why do normal users have the option of changing to sysadm?                                 
>                                                                                              
> That's a Red Hat addition to the policy.                                                     

How do I make it go away? I thought it was a matter of removing the
transition from sysadm to user in
/etc/security/selinux/src/policy/domains/user.te and then reloading,
but this doesn't seem to work. I suspect this is probably the reverse
of the transition I want to disable anyways.

> > I don't particularly like this, and I could remove it, but I'm                             
> > looking for the reasoning behind the default being like this.                              
>                                                                                              
> Basically to make the SELinux experience more like a "normal" Linux                          
> system.                                                                                      

In what ways?

-- 
Chris Grier <grier@uiuc.edu>

--
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: policy questions and bugs

[Russell Coker]

On Thu, 20 May 2004 06:07, Chris Grier <grier@uiuc.edu> wrote:
> > > Why do normal users have the option of changing to sysadm?
> >
> > That's a Red Hat addition to the policy.
>
> How do I make it go away? I thought it was a matter of removing the

Comment out the definition of user_canbe_sysadm in tunable.te (put "dnl" at 
the start of the line), then load the policy.

-- 
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: policy questions and bugs

[Luke Kenneth Casson Leighton]

On Wed, May 19, 2004 at 03:07:59PM -0500, Chris Grier wrote:
> > ----- Forwarded message from Colin Walters <walters@verbum.org> -----
> >                                                                                              
> > > When running some services, I would like them to run as a non root uid                     
> > > and gid (ircd and oidentd are the services which I usually do this                         
> > > with), which I normally do with su. When we do this with selinux                           
> > > running, we are prompted to enter a role and type (not select from a                       
> > > list). Is this just a matter of defining a transition to acommodate for                    
> > > this to happen?                                                                            
> >                                                                                              
> > You run "su" interactively from a root shell?  I'd suggest instead using                     
> > init scripts.                                                                                
> 
> No, not interactively. I am trying to use the init scripts. The way it
> works is the init function daemon() (from /etc/init.d/functions)
> accepts a --user argument to run the daemon as a given user. 

 oo.  ah.  yes, i have some scripts that need to be run under
 specific user contexts, too.

 i use /sbin/start-stop-daemon with a "-u lkcl" argument.

 is /sbin/start-stop-daemon going to need to be updated, too,
 to have a get_default_context() call in it?

 l.


--
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: policy questions and bugs

[Russell Coker]

On Sat, 15 May 2004 13:30, Chris Grier <grier@uiuc.edu> wrote:
> I have a whole bunch of questions after reading the FAQ and some other
> random documents I found for selinux, here they are:
>
> The dpkg and rpm both have apt-get in their domain te files. fixfiles
> doesn't like having multiple contexts defined for a single file. This
> might be a bug.

You should not have both dpkg.te and rpm.te in the same policy.

> When running some services, I would like them to run as a non root uid
> and gid (ircd and oidentd are the services which I usually do this
> with), which I normally do with su. When we do this with selinux
> running, we are prompted to enter a role and type (not select from a
> list). Is this just a matter of defining a transition to acommodate for
> this to happen?

It's best to have a program such as the Debian program start-stop-daemon to 
run a program under a different UID.

> Last question for today, when creating my own fc and te files to build
> into the policy, is it safe to create them in the policy/src directory,
> or will future package updates simply overwrite them and kill all the
> stuff I'm writing? How about modifications of existing files in the
> policy source directory?

That's a distribution issue.  Colin has described the Red Hat system, in 
Debian you are asked about all file change/replace operations in the policy 
(this can result in many questions being asked on upgrade).

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