Gentoo Archives: gentoo-hardened

From: Sven Vermeulen <swift@g.o>
To: gentoo-hardened@l.g.o
Subject: Re: [gentoo-hardened] Thoughts on these AVC denials
Date: Thu, 25 Oct 2012 09:02:44
Message-Id: CAPzO=Nz2+2_WfCzLQpu97OsxaSQo8uaK1gG4L2n4JpROxBa54g@mail.gmail.com
In Reply to: Re: [gentoo-hardened] Thoughts on these AVC denials by Stan Sander
1 Try running it in enforcing and document the application failures you get
2 together with their denials. And see if allowing it fixes that particular
3 problem. If you just give a list with rules and say "this is needed" there
4 is a realistic chance that I can't get it upstreamed.
5 On Oct 25, 2012 12:24 AM, "Stan Sander" <stsander@×××××.net> wrote:
6
7 > On 10/24/2012 08:46 AM, Sven Vermeulen wrote:
8 > > On Tue, Oct 23, 2012 at 12:50:22PM -0600, Stan Sander wrote:
9 > >> This is the invalid context that I think I need to address:
10 > >>
11 > >> Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.497:8823983):
12 > >> security_compute_sid: invalid context stan:system_r:initrc_t for
13 > >> scontext=stan:sysadm_r:sysadm_t
14 > >> tcontext=system_u:object_r:asterisk_initrc_exec_t tclass=process
15 > >>
16 > > Meh,
17 > >
18 > > Seems my reply didn't hit the list first.
19 > >
20 > > You probably forgot to add in the system_r role to the SELinux user, see
21 > >
22 > http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml?part=2&chap=1#serviceadmin
23 > >
24 > > Wkr,
25 > > Sven Vermeulen
26 >
27 > Thanks, asterisk now starts with SELinux enforcing. However, it did
28 > produce some new denials, two of which I believe impact the correct
29 > running of the daemon and associated scripts, etc. Here are all the
30 > denials generated at startup:
31 >
32 > Oct 24 15:48:45 iax kernel: type=1400 audit(1351115325.194:8824301):
33 > avc: denied { entrypoint } for pid=14590 comm="runscript.sh"
34 > path="/bin/rm" dev="sda3" ino=6837732 scontext=stan:system_r:initrc_t
35 > tcontext=system_u:object_r:bin_t tclass=file
36 > Oct 24 15:48:45 iax kernel: type=1400 audit(1351115325.203:8824302):
37 > avc: denied { read write } for pid=14592 comm="asterisk"
38 > path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t
39 > tcontext=stan:object_r:user_devpts_t tclass=chr_file
40 > Oct 24 15:48:45 iax kernel: type=1400 audit(1351115325.203:8824303):
41 > avc: denied { read write } for pid=14592 comm="asterisk"
42 > path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t
43 > tcontext=stan:object_r:user_devpts_t tclass=chr_file
44 > Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.462:8824304):
45 > avc: denied { write } for pid=14669 comm="runscript.sh"
46 > name="wrapper_loop.pid" dev="sda3" ino=6422541
47 > scontext=stan:system_r:initrc_t
48 > tcontext=stan:object_r:asterisk_var_run_t tclass=file
49 > Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.464:8824305):
50 > avc: denied { read write } for pid=14670 comm="asterisk"
51 > path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t
52 > tcontext=stan:object_r:user_devpts_t tclass=chr_file
53 > Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.464:8824306):
54 > avc: denied { read write } for pid=14670 comm="asterisk"
55 > path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t
56 > tcontext=stan:object_r:user_devpts_t tclass=chr_file
57 > Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.469:8824307):
58 > avc: denied { setattr } for pid=14670 comm="asterisk" name="asterisk"
59 > dev="sda3" ino=6446976 scontext=stan:system_r:asterisk_t
60 > tcontext=system_u:object_r:asterisk_var_run_t tclass=dir
61 >
62 >
63 >
64 > The write denial for the wrapper_loop.pid file will lead to trouble, and
65 > the denial for setattr on the /var/run/asterisk directory has the
66 > potential (IMHO) to get us off in the weeds. The others, AFAICT are
67 > candidates for dontaudit rules. Based on the above, it seems initrc_t
68 > needs to be allowed to write asterisk_var_run_t files. Since
69 > runscript.sh is trying to write the pid, I really don't see any
70 > alternatives. I believe it needs this info to properly signal the
71 > wrapper for a graceful daemon stoppage. The last denial (for setattr)
72 > is trying to ensure 770 permissions on /var/run/asterisk and likely user
73 > and group ownership also.
74 >
75 > I can throw a couple rules at this in a local policy module, and let
76 > this run for a few days to see if anything else pops out, then file what
77 > I find in a bug against the policy module.
78 >
79 > --
80 > Stan & HD Tashi Grad 10/08 Edgewood, NM SWR
81 > PR - Cindy and Jenny - Sammamish, WA NWR
82 > http://www.cci.org
83 >
84 >
85 >

Replies

Subject Author
Re: [gentoo-hardened] Thoughts on these AVC denials Stan Sander <stsander@×××××.net>