From: pebenito@ieee.org (Chris PeBenito) Date: Sat, 31 Dec 2016 10:43:59 -0500 Subject: [refpolicy] [PATCH] init: update the initrc_t domain policy In-Reply-To: <1483131183.2613.4.camel@trentalancia.net> References: <1483051782.12123.10.camel@trentalancia.net> <1483128957.3970.18.camel@trentalancia.net> <1483131183.2613.4.camel@trentalancia.net> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 12/30/16 15:53, Guido Trentalancia via refpolicy wrote: > On Fri, 30/12/2016 at 21.15 +0100, Guido Trentalancia via refpolicy > wrote: >> On Fri, 30/12/2016 at 14.30 -0500, Chris PeBenito wrote: >>> On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote: >>>> @@ -462,6 +466,8 @@ dev_getattr_all_blk_files(initrc_t) >>>> dev_getattr_all_chr_files(initrc_t) >>>> # Early devtmpfs >>>> dev_rw_generic_chr_files(initrc_t) >>>> +# mcelog service >>>> +dev_read_kmsg(initrc_t) >>> >>> mcelog is a service, so it shouldn't be running in initrc_t. >> >> You see, unfortunately, the mcelog.init script, has a limitation in >> that sense because it checks that /dev/mcelog is readable otherwise >> it >> exits without starting the mcelog service. >> >> It's not a bug strictly speaking, however, it causes such limitation >> in >> the security domain. >> >> Of course, mcelog then runs in its own domain... > > Actually, the mcelog init script does not exit, however it prints an > (annoying and false) error message about /dev/mcelog not being active ! > > I think we'd better keep the dev_read_kmsg(initrc_t) permission, > although theoretically it could be removed. Which distro is this on? The Gentoo init script doesn't do that. -- Chris PeBenito