From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Fri, 21 Dec 2012 21:17:39 +0100
Subject: [refpolicy] [PATCH 5/8] Dontaudit getsched on all domains
In-Reply-To: <20121217102603.GA1030@siphos.be>
References: <1355737370-27628-1-git-send-email-sven.vermeulen@siphos.be>
	<1355737370-27628-6-git-send-email-sven.vermeulen@siphos.be>
	<1355739655.2269.7.camel@localhost>
	<20121217102603.GA1030@siphos.be>
Message-ID: <20121221201739.GA6960@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, Dec 17, 2012 at 11:26:04AM +0100, Sven Vermeulen wrote:
> > > --- a/policy/modules/system/userdomain.if
> > > +++ b/policy/modules/system/userdomain.if
> > > @@ -523,6 +523,8 @@ template(`userdom_common_user_template',`
> > >  	dev_read_sound_mixer($1_t)
> > >  	dev_write_sound_mixer($1_t)
> > >  
> > > +	domain_dontaudit_getsched_all_domains($1_t)
> > 
> > That is too coarse in my view.
> > 
> > This will also dontaudit legitimate access for processes needing this
> > running in the user domain.
> > 
> > Lets say i have this app that depends on this permission for itself:
> > 
> > allow staff_t self:process { signal getsched };
> > 
> > Then this rule will silently hide that access
> 
> I understand that, but the other method would be to create
> *_dontaudit_getsched for each and every possible module, and add it in the
> user domain definition fully loaded with optional_policy() statements.
> 
> And if the user domain doesn't need getsched itself, then running htop will
> generate denials anyhow for self (i.e. in your above example, you'll get
> denials for staff_t getsched on itself) so eventually you'll add in a
> staff_dontaudit_getsched() for that too?
> 
> Another alternative could be to run htop in its own domain, but that doesn't
> make sense imo...

Chris, what is your take on this?

Wkr,
	Sven Vermeulen