Humpty Dumpty

[Stephen Smalley]

On Tue, 2004-05-04 at 15:50, Bob Gustafson wrote:
> Yesterday I downloaded some of the SELinux tool stuff and rebuilt it
> from the SRPMS. (This may not have been necessary).

yum install setools*

> The application 'seuser' did not seem to be able to find the policy.conf
> file. I found the .tcl file and hacked a bit on that, but tcl is not a
> native language for me. (Today I found the /usr/share/setools/seuser.conf
> file with the missing 'policy' in the policy.conf path)

Known breakage, reported to the maintainers (Tresys).

> Also there was something about the file_contexts - it was a file instead
> of a directory at one point - so I deleted the file and redid some steps
> and found a populated directory afterwards - so I must have done
> something (correctly?).

There is an installed file_contexts in /etc/security/selinux for runtime
use, and if you have policy-sources installed, there is also the
/etc/security/selinux/src/policy/file_contexts directory that contains
the sources.

> I went in with vim and changed the last line to read '--disabled' and
> then attempted to reboot the SELinux enabled system.

Wrong file.  /etc/sysconfig/selinux, content should be SELINUX=disabled
(or enforcing or permissive).

> My immediate objective is to configure things so that I can turn
> enforcing on and successfully boot my system. Maybe this is not yet
> possible (not enough file_contexts set?).

Try running fixfiles relabel from single user mode, then reboot.

> What versions of what software are currently SElinux enabled. I have rpm
> 4.3.1 - does that rpm do the right thing as far as installing the extra
> file contexts?

Yes.

> What happens if I do an up2date. Will I load in non-SELinux programs which
> will undo everything learned up to that point?

yum update works correctly; I would expect up2date to do likewise, but
am not certain.

> What is rawhide? Is that a collection of setools? (or an ancient Fedora image?)

Fedora devel tree.

> How can I make the file context messages go away -correctly- (i.e., by
> setting the file contexts)?  Is there a mass process that will tweek all
> files?

fixfiles relabel, best done from single user mode.

>    hoho2 login: user1
>    Password:
>    Last login: Tue May  4 10:41:38 from TZ
>    [user1 at hoho2 user1]$ su
>    Password:
>    audit(1083685732.396:0): avc:  denied  { transition } for  pid=2176
>    exe=/bin/su
>    path=/bin/bash dev=sda2 ino=2605063 scontext=user_u:sysadm_r:sysadm_t
>    tcontext=r
>    oot:sysadm_r:sysadm_t tclass=process
> 
> I can guess that something is objectionable here, but see below when I did
> it again

su program wasn't labeled properly, so it didn't run in the right domain
and lacked permission (but you aren't in enforcing mode).

> See, here I did another su, but did not get log messages. Why?

In permissive mode, SELinux only logs once per denial to avoid floods,
because the application may very well keep performing the same operation
endlessly since it isn't getting any denial (strictly speaking, it logs
once per denial or until the cache entry is evicted, e.g. by a policy
reload or just in the normal course of operation).

>    May  4 10:48:52 hoho2 kernel: audit(1083685732.396:0): avc:  denied
>    { transition } for  pid=2176 exe=/bin/su path=/bin/bash dev=sda2
> ino=2605063
>    scontext=user_u:sysadm_r:sysadm_t tcontext=root:sysadm_r:sysadm_t
> tclass=process

The su process, running in the "scontext" (source security context), was
denied process transition permission to the "tcontext" (target security
context), so in enforcing mode, it would have been prevented from
changing to the administrative role/domain.  This is because su wasn't
labeled properly, and the original user domain isn't authorized to
directly transition (for obvious reasons).

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency