From: dsugar@tresys.com (David Sugar) Date: Thu, 14 Sep 2017 14:51:49 +0000 Subject: [refpolicy] [PATCH 1/1] Add int_rlimit_inherit interface In-Reply-To: <20170914142758.GD17010@julius.enp8s0.d30> References: <1B50C12ACFF4CB42B90D2581155DF50205B5D882@Exchange10.columbia.tresys.com> <20170914080744.GA17010@julius.enp8s0.d30> <20170914082010.GB17010@julius.enp8s0.d30> <1B50C12ACFF4CB42B90D2581155DF50205B5ECA2@Exchange10.columbia.tresys.com> <20170914141334.GC17010@julius.enp8s0.d30> <20170914142758.GD17010@julius.enp8s0.d30> Message-ID: <1B50C12ACFF4CB42B90D2581155DF50205B5ED7F@Exchange10.columbia.tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com > -----Original Message----- > From: refpolicy-bounces at oss.tresys.com [mailto:refpolicy- > bounces at oss.tresys.com] On Behalf Of Dominick Grift via refpolicy > Sent: Thursday, September 14, 2017 10:28 AM > To: refpolicy at oss.tresys.com > Subject: Re: [refpolicy] [PATCH 1/1] Add int_rlimit_inherit interface > > On Thu, Sep 14, 2017 at 04:13:34PM +0200, Dominick Grift wrote: > > On Thu, Sep 14, 2017 at 01:45:19PM +0000, David Sugar via refpolicy > wrote: > > > > > > ________________________________________ > > > From: refpolicy-bounces at oss.tresys.com > > > [refpolicy-bounces at oss.tresys.com] on behalf of Dominick Grift via > > > refpolicy [refpolicy at oss.tresys.com] > > > Sent: Thursday, September 14, 2017 4:20 AM > > > To: refpolicy at oss.tresys.com > > > Subject: Re: [refpolicy] [PATCH 1/1] Add int_rlimit_inherit > > > interface > > > > > > On Thu, Sep 14, 2017 at 10:07:44AM +0200, Dominick Grift wrote: > > > > On Wed, Sep 13, 2017 at 08:34:15PM +0000, David Sugar via > refpolicy wrote: > > > > > Create new interface init_rlimit_inherit to allow a process > started by init to inherit resource limits. systemd allows for setting > of resource limits [1] but the default from SELinux is to not allow the > inheritance of those limits as a service is started. This interface > allows that resource limit inheritance. > > > > > > > > > > The systemd .service options are LimitCPU=, LimitFSIZE=, > > > > > LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=, LimitNOFILE=, > > > > > LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=, > > > > > LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=, > > > > > LimitRTTIME= > > > > > > > > > > [1] > > > > > https://www.freedesktop.org/software/systemd/man/systemd.exec.ht > > > > > ml > > > > > > > > Have you tested this? > > > > > > > > I just tried this out and i do not seem to need this to get it to > work: > > > > > > > > https://www.youtube.com/watch?v=f8nFGbMBG0s > > > > > > > > Instead systemd needs to be able to "setrlimit" (and probably > > > > getsched/setsched) on its children i suspect > > > > > > I tested this in the use case that I am working with. I am setting > LimitMSGQUEUE=infinity in my .service file. The service is starting a > c++ binary which is creating a message queue (using mq_open) with a > fairly large message queue size. > > > I was getting failures to create the message queue (I'm pretty sure > the error was EMFILE - I don't have the error message returned from > mq_open handy any longer I can rebuild the policy and retest if you > would like). > > > Once I added this permission (and only this one change) the error > went away. > > > > I can't produce this: > > > > https://www.youtube.com/watch?v=yRcyBQfkKoE > > That test isnt right, but i redid it and it just doesnt even try to > rlimitinh In other words the event you allow doesnt even happen IMHO > > Did you even see an avc denial before you decided to allow this? Or did > you assume that this would be needed? I wasn't seeing any denials (which made it harder to diagnose the problem). The problem being the failure of mq_open only when in enforcing. But when I turn off dontaudit's (semodule -DB) I saw that every processes that is exec'ed has denials for noatsecure, siginh, and rlimitinh (from domain_transition_pattern). I then looked up exactly what those permissions were and rlimitinh sounded like something reasonable to try. I then manually added a rule to my policy to grant that permission and then the problem went away. After that I created the interface in init.if and again verified the problem was still solved. I will try to create a simple binary to reproduce the problem I'm seeing. Other information that might make a difference, I am running using CentOS 7.3.1611, systemd-219-30.el7_3.9. Dave > > > > > > > > > I did watch your video and I'm not sure what the difference is > between the two cases. I don't know if making it a bash script is > somehow making a difference (I don't know why it would)? > > > > > > I am also using the SELinuxContext= option to explicitly set the > target domain. I also don't think this would make a difference, but I > wanted to mention it. > > > > > > Dave Sugar > > > > > > > > > > > > > > > > > Signed-off-by: Dave Sugar > > > > > --- > > > > > policy/modules/system/init.if | 23 +++++++++++++++++++++++ > > > > > 1 file changed, 23 insertions(+) > > > > > > > > > > diff --git a/policy/modules/system/init.if > > > > > b/policy/modules/system/init.if index 09a20311..bf6e37bc 100644 > > > > > --- a/policy/modules/system/init.if > > > > > +++ b/policy/modules/system/init.if > > > > > @@ -712,6 +712,29 @@ interface(`init_getpgid',` > > > > > > > > > > ######################################## > > > > > ## > > > > > +## Allow process to inherit resource limits. > > > > > +## > > > > > +##

> > > > > +## This is applicable with systemd when using the ## options to > > > > > +limit resources - see ## > > > > > +https://www.freedesktop.org/software/systemd/man/systemd.exec.h > > > > > +tml#LimitMSGQUEUE= > > > > > +##

> > > > > +## > > > > > +## > > > > > +## Domain allowed access. > > > > > +## > > > > > +## > > > > > +# > > > > > +interface(`init_rlimit_inherit',` > > > > > + gen_require(` > > > > > + type init_t; > > > > > + ') > > > > > + > > > > > + allow $1 init_t:process rlimitinh; > > > > > +') > > > > > + > > > > > +######################################## > > > > > +## > > > > > ## Send init a generic signal. > > > > > ## > > > > > ## > > > > > -- > > > > > 2.13.5 > > > > > _______________________________________________ > > > > > refpolicy mailing list > > > > > refpolicy at oss.tresys.com > > > > > http://oss.tresys.com/mailman/listinfo/refpolicy > > > > > > > > -- > > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B > > > > 6B02 > > > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B > > > > 6B02 > > > > Dominick Grift > > > > > > > > > > > > -- > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B > > > 02 > > > Dominick Grift > > > _______________________________________________ > > > refpolicy mailing list > > > refpolicy at oss.tresys.com > > > http://oss.tresys.com/mailman/listinfo/refpolicy > > > > -- > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 > > Dominick Grift > > > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 > Dominick Grift