Re: policy questions and bugs

[Colin Walters <walters@verbum.org>]

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