Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Gentoo>
  3. Hardened
Thoughts on these AVC denials
stsander at sblan
Oct 23, 2012, 11:50 AM
Post #1 of 5 (2108 views)
Permalink
I'm trying to work on getting SELinux running in enforcing mode on my
x86 stable server. Everything seems OK if I switch enforcing on until
asterisk needs to be (re)started. Running /etc/init.d/asterisk results
in a bad interpreter (permission denied) error if SELinux is enforcing.
Only thing that I noticed in the logs was an invalid security context.
So today I disabled all the dontaudit rules and ran the init script (in
permissive mode) from the command line. The invalid context seems to be
the root of the issue, but here are the AVC that I captured. I'm not
sure the best way to handle the invalid context. So I'd like to get
some thoughts/suggestions from the list before I start making changes.

This is the invalid context that I think I need to address:

Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.497:8823983):
security_compute_sid: invalid context stan:system_r:initrc_t for
scontext=stan:sysadm_r:sysadm_t
tcontext=system_u:object_r:asterisk_initrc_exec_t tclass=process

By way of context, here are all the denials as they appeared.

Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.497:8823983):
security_compute_sid: invalid context stan:system_r:initrc_t for
scontext=stan:sysadm_r:sysadm_t
tcontext=system_u:object_r:asterisk_initrc_exec_t tclass=process
Oct 23 11:47:21 iax kernel: type=1400 audit(1351014441.497:8823984):
avc: denied { rlimitinh } for pid=10978 comm="asterisk"
scontext=stan:sysadm_r:sysadm_t tcontext=stan:system_r:initrc_t
tclass=process
Oct 23 11:47:21 iax kernel: type=1400 audit(1351014441.497:8823985):
avc: denied { siginh } for pid=10978 comm="asterisk"
scontext=stan:sysadm_r:sysadm_t tcontext=stan:system_r:initrc_t
tclass=process
Oct 23 11:47:21 iax kernel: type=1400 audit(1351014441.497:8823986):
avc: denied { noatsecure } for pid=10978 comm="asterisk"
scontext=stan:sysadm_r:sysadm_t tcontext=stan:system_r:initrc_t
tclass=process
Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.500:8823987):
security_compute_sid: invalid context stan:system_r:initrc_t for
scontext=stan:system_r:initrc_t tcontext=system_u:object_r:rc_exec_t
tclass=process
Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.508:8823988):
security_compute_sid: invalid context stan:system_r:initrc_t for
scontext=stan:system_r:initrc_t tcontext=system_u:object_r:bin_t
tclass=process
Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.515:8823989):
security_compute_sid: invalid context stan:system_r:initrc_t for
scontext=stan:system_r:initrc_t tcontext=system_u:object_r:bin_t
tclass=process
Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.517:8823990):
security_compute_sid: invalid context stan:system_r:initrc_t for
scontext=stan:system_r:initrc_t tcontext=system_u:object_r:rc_exec_t
tclass=process
Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.530:8823991):
security_compute_sid: invalid context stan:system_r:initrc_t for
scontext=stan:system_r:initrc_t tcontext=system_u:object_r:bin_t
tclass=process
Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.542:8823992):
security_compute_sid: invalid context stan:system_r:initrc_t for
scontext=stan:system_r:initrc_t tcontext=system_u:object_r:bin_t
tclass=process
Oct 23 11:47:22 iax asterisk_wrapper: Initializing asterisk wrapper

And, the current file contexts:

#ls -lZ /etc/init.d/asterisk
-rwxr-xr-x. 1 root root system_u:object_r:asterisk_initrc_exec_t 6489
Oct 5 13:12 /etc/init.d/asterisk
#ls -lZ /usr/sbin/asterisk
-rwxr-xr-x. 1 root root system_u:object_r:asterisk_exec_t 24247031 Oct
5 13:01 /usr/sbin/asterisk

The resulting processes show:

#ps -efZ |grep asterisk
stan:system_r:initrc_t root 11062 1 0 11:47 pts/2
00:00:00 /bin/sh /lib/rc/sh/runscript.sh /etc/init.d/asterisk start
stan:system_r:initrc_t root 11063 1 0 11:47 pts/2
00:00:00 logger -t asterisk_wrapper
stan:system_r:asterisk_t asterisk 11066 11062 0 11:47 pts/2
00:00:01 /usr/sbin/asterisk -f -g -U asterisk
stan:system_r:asterisk_t asterisk 11067 11066 0 11:47 pts/2
00:00:00 astcanary
/var/run/asterisk/alt.asterisk.canary.tweet.tweet.tweet 11066

Which is interesting that they are running under my SELinux user name
instead of system_u like other processes I may need to (re)start in a
similar fashion. Also the asterisk script does not seem to call/use
runscript_selinux.so like the others do as I am not prompted for root's
password.

And lastly, my shell that I am executing all of this from:

#id
uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),11(floppy),26(tape),27(video)
context=stan:sysadm_r:sysadm_t

--
Stan & HD Tashi Grad 10/08 Edgewood, NM SWR
PR - Cindy and Jenny - Sammamish, WA NWR
http://www.cci.org

Attached Files:

Re: Thoughts on these AVC denials [ In reply to ]
swift at gentoo
Oct 24, 2012, 7:46 AM
Post #2 of 5 (2069 views)
Permalink
On Tue, Oct 23, 2012 at 12:50:22PM -0600, Stan Sander wrote:
> This is the invalid context that I think I need to address:
>
> Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.497:8823983):
> security_compute_sid: invalid context stan:system_r:initrc_t for
> scontext=stan:sysadm_r:sysadm_t
> tcontext=system_u:object_r:asterisk_initrc_exec_t tclass=process
>

Meh,

Seems my reply didn't hit the list first.

You probably forgot to add in the system_r role to the SELinux user, see
http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml?part=2&chap=1#serviceadmin

Wkr,
Sven Vermeulen
Re: Thoughts on these AVC denials [ In reply to ]
stsander at sblan
Oct 24, 2012, 3:22 PM
Post #3 of 5 (2092 views)
Permalink
On 10/24/2012 08:46 AM, Sven Vermeulen wrote:
> On Tue, Oct 23, 2012 at 12:50:22PM -0600, Stan Sander wrote:
>> This is the invalid context that I think I need to address:
>>
>> Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.497:8823983):
>> security_compute_sid: invalid context stan:system_r:initrc_t for
>> scontext=stan:sysadm_r:sysadm_t
>> tcontext=system_u:object_r:asterisk_initrc_exec_t tclass=process
>>
> Meh,
>
> Seems my reply didn't hit the list first.
>
> You probably forgot to add in the system_r role to the SELinux user, see
> http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml?part=2&chap=1#serviceadmin
>
> Wkr,
> Sven Vermeulen

Thanks, asterisk now starts with SELinux enforcing. However, it did
produce some new denials, two of which I believe impact the correct
running of the daemon and associated scripts, etc. Here are all the
denials generated at startup:

Oct 24 15:48:45 iax kernel: type=1400 audit(1351115325.194:8824301):
avc: denied { entrypoint } for pid=14590 comm="runscript.sh"
path="/bin/rm" dev="sda3" ino=6837732 scontext=stan:system_r:initrc_t
tcontext=system_u:object_r:bin_t tclass=file
Oct 24 15:48:45 iax kernel: type=1400 audit(1351115325.203:8824302):
avc: denied { read write } for pid=14592 comm="asterisk"
path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t
tcontext=stan:object_r:user_devpts_t tclass=chr_file
Oct 24 15:48:45 iax kernel: type=1400 audit(1351115325.203:8824303):
avc: denied { read write } for pid=14592 comm="asterisk"
path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t
tcontext=stan:object_r:user_devpts_t tclass=chr_file
Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.462:8824304):
avc: denied { write } for pid=14669 comm="runscript.sh"
name="wrapper_loop.pid" dev="sda3" ino=6422541
scontext=stan:system_r:initrc_t
tcontext=stan:object_r:asterisk_var_run_t tclass=file
Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.464:8824305):
avc: denied { read write } for pid=14670 comm="asterisk"
path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t
tcontext=stan:object_r:user_devpts_t tclass=chr_file
Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.464:8824306):
avc: denied { read write } for pid=14670 comm="asterisk"
path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t
tcontext=stan:object_r:user_devpts_t tclass=chr_file
Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.469:8824307):
avc: denied { setattr } for pid=14670 comm="asterisk" name="asterisk"
dev="sda3" ino=6446976 scontext=stan:system_r:asterisk_t
tcontext=system_u:object_r:asterisk_var_run_t tclass=dir



The write denial for the wrapper_loop.pid file will lead to trouble, and
the denial for setattr on the /var/run/asterisk directory has the
potential (IMHO) to get us off in the weeds. The others, AFAICT are
candidates for dontaudit rules. Based on the above, it seems initrc_t
needs to be allowed to write asterisk_var_run_t files. Since
runscript.sh is trying to write the pid, I really don't see any
alternatives. I believe it needs this info to properly signal the
wrapper for a graceful daemon stoppage. The last denial (for setattr)
is trying to ensure 770 permissions on /var/run/asterisk and likely user
and group ownership also.

I can throw a couple rules at this in a local policy module, and let
this run for a few days to see if anything else pops out, then file what
I find in a bug against the policy module.

--
Stan & HD Tashi Grad 10/08 Edgewood, NM SWR
PR - Cindy and Jenny - Sammamish, WA NWR
http://www.cci.org

Attached Files:

Re: Thoughts on these AVC denials [ In reply to ]
swift at gentoo
Oct 25, 2012, 12:18 AM
Post #4 of 5 (2066 views)
Permalink
Try running it in enforcing and document the application failures you get
together with their denials. And see if allowing it fixes that particular
problem. If you just give a list with rules and say "this is needed" there
is a realistic chance that I can't get it upstreamed.
On Oct 25, 2012 12:24 AM, "Stan Sander" <stsander@sblan.net> wrote:

> On 10/24/2012 08:46 AM, Sven Vermeulen wrote:
> > On Tue, Oct 23, 2012 at 12:50:22PM -0600, Stan Sander wrote:
> >> This is the invalid context that I think I need to address:
> >>
> >> Oct 23 11:47:21 iax kernel: type=1401 audit(1351014441.497:8823983):
> >> security_compute_sid: invalid context stan:system_r:initrc_t for
> >> scontext=stan:sysadm_r:sysadm_t
> >> tcontext=system_u:object_r:asterisk_initrc_exec_t tclass=process
> >>
> > Meh,
> >
> > Seems my reply didn't hit the list first.
> >
> > You probably forgot to add in the system_r role to the SELinux user, see
> >
> http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml?part=2&chap=1#serviceadmin
> >
> > Wkr,
> > Sven Vermeulen
>
> Thanks, asterisk now starts with SELinux enforcing. However, it did
> produce some new denials, two of which I believe impact the correct
> running of the daemon and associated scripts, etc. Here are all the
> denials generated at startup:
>
> Oct 24 15:48:45 iax kernel: type=1400 audit(1351115325.194:8824301):
> avc: denied { entrypoint } for pid=14590 comm="runscript.sh"
> path="/bin/rm" dev="sda3" ino=6837732 scontext=stan:system_r:initrc_t
> tcontext=system_u:object_r:bin_t tclass=file
> Oct 24 15:48:45 iax kernel: type=1400 audit(1351115325.203:8824302):
> avc: denied { read write } for pid=14592 comm="asterisk"
> path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t
> tcontext=stan:object_r:user_devpts_t tclass=chr_file
> Oct 24 15:48:45 iax kernel: type=1400 audit(1351115325.203:8824303):
> avc: denied { read write } for pid=14592 comm="asterisk"
> path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t
> tcontext=stan:object_r:user_devpts_t tclass=chr_file
> Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.462:8824304):
> avc: denied { write } for pid=14669 comm="runscript.sh"
> name="wrapper_loop.pid" dev="sda3" ino=6422541
> scontext=stan:system_r:initrc_t
> tcontext=stan:object_r:asterisk_var_run_t tclass=file
> Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.464:8824305):
> avc: denied { read write } for pid=14670 comm="asterisk"
> path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t
> tcontext=stan:object_r:user_devpts_t tclass=chr_file
> Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.464:8824306):
> avc: denied { read write } for pid=14670 comm="asterisk"
> path="/dev/pts/2" dev="devpts" ino=5 scontext=stan:system_r:asterisk_t
> tcontext=stan:object_r:user_devpts_t tclass=chr_file
> Oct 24 15:48:46 iax kernel: type=1400 audit(1351115326.469:8824307):
> avc: denied { setattr } for pid=14670 comm="asterisk" name="asterisk"
> dev="sda3" ino=6446976 scontext=stan:system_r:asterisk_t
> tcontext=system_u:object_r:asterisk_var_run_t tclass=dir
>
>
>
> The write denial for the wrapper_loop.pid file will lead to trouble, and
> the denial for setattr on the /var/run/asterisk directory has the
> potential (IMHO) to get us off in the weeds. The others, AFAICT are
> candidates for dontaudit rules. Based on the above, it seems initrc_t
> needs to be allowed to write asterisk_var_run_t files. Since
> runscript.sh is trying to write the pid, I really don't see any
> alternatives. I believe it needs this info to properly signal the
> wrapper for a graceful daemon stoppage. The last denial (for setattr)
> is trying to ensure 770 permissions on /var/run/asterisk and likely user
> and group ownership also.
>
> I can throw a couple rules at this in a local policy module, and let
> this run for a few days to see if anything else pops out, then file what
> I find in a bug against the policy module.
>
> --
> Stan & HD Tashi Grad 10/08 Edgewood, NM SWR
> PR - Cindy and Jenny - Sammamish, WA NWR
> http://www.cci.org
>
>
>
Re: Thoughts on these AVC denials [ In reply to ]
stsander at sblan
Oct 25, 2012, 7:41 AM
Post #5 of 5 (2055 views)
Permalink
On 10/25/2012 01:18 AM, Sven Vermeulen wrote:
>
> Try running it in enforcing and document the application failures you
> get together with their denials. And see if allowing it fixes that
> particular problem. If you just give a list with rules and say "this
> is needed" there is a realistic chance that I can't get it upstreamed.
>
After sending this message and thinking about it, that's exactly what I
decided to do. So far everything is running OK despite what I thought
when I first saw the denials.

--
Stan & HD Tashi Grad 10/08 Edgewood, NM SWR
PR - Cindy and Jenny - Sammamish, WA NWR
http://www.cci.org

Attached Files:

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal