Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Hardened (http://www.linux-archive.org/gentoo-hardened/)
-   -   Excessive SELinux avc denials (http://www.linux-archive.org/gentoo-hardened/4168-excessive-selinux-avc-denials.html)

Will Keaney 11-24-2007 03:50 PM

Excessive SELinux avc denials
 
On Tue, 20 Nov 2007 09:16:03 +0100
Julien Thomas <julien.thomas@enst-bretagne.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@sharerland.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@sharerland.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

Will Keaney 11-24-2007 04:01 PM

Excessive SELinux avc denials
 
On Tue, 20 Nov 2007 09:16:03 +0100
Julien Thomas <julien.thomas@enst-bretagne.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.
I also wanted to mention, just in case someone else is ever looking
for this information, that I found descriptions of the booleans
in /usr/share/selinux/strict/include/

Regards,

Will


All times are GMT. The time now is 12:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.