Re: [gentoo-hardened] Excessive SELinux avc denials

[Will Keaney]

On Tue, 20 Nov 2007 09:16:03 +0100
Julien Thomas <julien.thomas@×××××××××××××.fr> wrote:

> Hi.
>
> When I tried to analyze booleans, I used http://linux.die.net/man/8/
>
> It does not described each boolean options,but if you take a look at a
> Linux option (see for instance nfs_selinux), you will find the
> associated booleans with their goals.
>
> According to me, you can also take a look at the SELinux sources, as
> most of the times :
> - boolean name are quite explicit
> - looking at the allowded rules by the boolean gives clues about the
> boolean goal.
>
> For courier-imap and sasl booleans, you can also take a look at the
> documentations I made about the policies (see my previous messages of
> the list, talking about policies upgrade proposals).
>
> Julien.
>
>
> Will Keaney a écrit :
> > On Sun, 18 Nov 2007 18:25:17 -0500
> > Bill Sharer <bsharer@××××××××××.com> wrote:
> >
> >> The booleans are in /selinux/booleans
> >>
> >> Use setsebool to change their value and/or make it permanent.
> >>
> >> Will Keaney wrote:
> >>> On Sun, 18 Nov 2007 16:56:55 -0500
> >>> Bill Sharer <bsharer@××××××××××.com> wrote:
> >>>
> >>>
> >>>> You can run the log through audit2why and audit2allow to get a
> >>>> feel for what's going on in policy.  Don't directly rely on
> >>>> audit2allow since I think it still orients itself to the old
> >>>> modular example policy and not refpolicy.
> >>>>
> >>>> Check your booleans.  I spotted one thing right off the bat
> >>>> (urandom) which is probably due to the boolean global_ssp not
> >>>> being true.  This should be true for gentoo systems, but for some
> >>>> reason, the ebuild defaults it to false.
> >>>>
> >>>> Will Keaney wrote:
> >>>>
> >>>>> I've just finished updating my SELinux VM, but still get a lot
> >>>>> of avc denials in /var/log/syslog.
> >>>>> What is the recommended method of changing
> >>>>> the SELinux policy?  I seem to remember PeBenito saying in IRC
> >>>>> that editing the policy files directly is not recommended.
> >>>>>
> >>>>> On the off chance that someone has some insight into what might
> >>>>> be causing these errors, I'm attaching the output of
> >>>>> grep "Nov 18 16:2" /var/log/syslog | cut -d " " -f 7- | grep avc
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Will Keaney
> >>>>> uberpinguin
> >>>>>
> >>>>>
> >>> Thanks very much for the quick reply, it is very informative.
> >>> I don't seem to have any booleans loaded, according to sestatus
> >>> -v: SELinux status:                 enabled
> >>> SELinuxfs mount:                /selinux
> >>> Current mode:                   permissive
> >>> Mode from config file:          permissive
> >>> Policy version:                 21
> >>> Policy from config file:        strict
> >>>
> >>> Process contexts:
> >>> Current context:                root:sysadm_r:sysadm_t
> >>> Init context:                   system_u:system_r:init_t
> >>> /sbin/agetty                    system_u:system_r:getty_t
> >>> /usr/sbin/sshd                  system_u:system_r:sshd_t
> >>>
> >>> File contexts:
> >>> Controlling term:               root:object_r:sysadm_tty_device_t
> >>> /sbin/init                      system_u:object_r:init_exec_t
> >>> /sbin/agetty                    system_u:object_r:getty_exec_t
> >>> /bin/login                      system_u:object_r:login_exec_t
> >>> /sbin/rc                        system_u:object_r:initrc_exec_t
> >>> /sbin/runscript.sh              system_u:object_r:initrc_exec_t
> >>> /usr/sbin/sshd                  system_u:object_r:sshd_exec_t
> >>> /sbin/unix_chkpwd               system_u:object_r:chkpwd_exec_t
> >>> /etc/passwd                     system_u:object_r:etc_t
> >>> /etc/shadow                     system_u:object_r:shadow_t
> >>> /bin/sh                         system_u:object_r:bin_t ->
> >>> system_u:object_r:shell_exec_t /bin/bash
> >>> system_u:object_r:shell_exec_t /usr/bin/newrole
> >>> system_u:object_r:newrole_exec_t /lib/libc.so.6
> >>> system_u:object_r:lib_t ->
> >>> system_u:object_r:shlib_t /lib/ld-linux.so.2
> >>> system_u:object_r:lib_t -> system_u:object_r:ld_so_t
> >>>
> >>> I don't see a command to load/change booleans though?
> >>>
> >>> Will
> >>>
> > Thanks very much.  Is there some sort of documentation for what
> > each of these booleans does?  Google is turning up a few mailing
> > list threads, but so far none have been very informative.
> > Once I've been through all of the booleans, what's the best way to
> > start adding allow rules?
> >
> > Thanks,
> >
> > Will
>
Thanks very much to Bill Sharer, Julien Thomas and Andrew Ross for your
helpful tips.  I've gotten many of the denials cleared up, but there
are still a few that are stumping me.

audit(1195922131.060:3): avc:  denied  { write } for  pid=924
comm="bash" name="null" dev=tmpfs ino=1804
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:device_t
tclass=chr_file audit(1195922131.580:4): avc:  denied  { read } for
pid=932 comm="write_root_link" name="console" dev=tmpfs ino=1798
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:device_t
tclass=chr_file 

audit(1195922135.024:5): avc:  denied  { read } for
pid=1015 comm="modprobe" name="console" dev=tmpfs ino=1798
scontext=system_u:system_r:insmod_t tcontext=system_u:object_r:device_t
tclass=chr_file 

audit(1195922135.032:6): avc:  denied  { write } for
pid=1015 comm="modprobe" name="null" dev=tmpfs ino=1804
scontext=system_u:system_r:insmod_t tcontext=system_u:object_r:device_t
tclass=chr_file 

audit(1195922135.332:7): avc:  denied  { getattr } for
pid=1026 comm="modprobe" name="null" dev=tmpfs ino=1804
scontext=system_u:system_r:insmod_t tcontext=system_u:object_r:device_t
tclass=chr_file 

audit(1195922175.333:8): avc:  denied  { append } for
pid=3425 comm="syslogd" name="syslog" dev=hda1 ino=475362
scontext=system_u:system_r:syslogd_t
tcontext=system_u:object_r:cron_log_t tclass=file

audit(1195922175.333:9): avc:  denied  { ioctl } for  pid=3425
comm="syslogd" name="syslog" dev=hda1 ino=475362
scontext=system_u:system_r:syslogd_t
tcontext=system_u:object_r:cron_log_t tclass=file

audit(1195922204.094:10): avc:  denied  { read } for  pid=4175
comm="bash" name=".bash_history" dev=hda1 ino=16389
scontext=root:staff_r:staff_t tcontext=root:object_r:sysadm_home_t
tclass=file

I've run this through audit2why and audit2allow, but the output isn't
particularly helpful at this point - audit2why simply says "Missing or
disabled TE allow rule," which is kind of a "Duh" statement;
audit2allow gives me the necessary allow rules, but I'm not sure what
to do with them:
allow initrc_t device_t:chr_file { read write };
allow insmod_t device_t:chr_file { getattr read write };
allow staff_t sysadm_home_t:file read;   
(I believe this is due to root logging in to the staff_r role by
default, but everything in /root/ being labeled with the sysadm_home_t
domain.  Is this intended behavior?)
allow syslogd_t cron_log_t:file { append ioctl };

Again, thank you for all your help.

Will