From: guido@trentalancia.com (Guido Trentalancia)
Date: Tue, 15 Mar 2011 14:40:14 +0100
Subject: [refpolicy] [PATCH 13/34]: patch to allow networkmanager dbus
 chat
In-Reply-To: <4D7E58BD.2020004@tresys.com>
References: <1297836836.3205.56.camel@tesla.lan>
	<4D651B7A.4010100@tresys.com> <1298487030.29671.20.camel@tesla.lan>
	<4D74E408.2050501@tresys.com> <1299517796.2978.41.camel@tesla.lan>
	<4D7533E5.9050806@tresys.com> <1299533995.2967.23.camel@tesla.lan>
	<4D7E0D25.5080304@tresys.com> <1300123406.3071.6.camel@tesla.lan>
	<4D7E58BD.2020004@tresys.com>
Message-ID: <1300196414.2977.10.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, 14/03/2011 at 14.04 -0400, Christopher J. PeBenito wrote:
> On 03/14/11 13:23, Guido Trentalancia wrote:
> > On Mon, 14/03/2011 at 08.42 -0400, Christopher J. PeBenito wrote:
> >> On 3/7/2011 4:39 PM, Guido Trentalancia wrote:
> >>> On Mon, 07/03/2011 at 14.37 -0500, Christopher J. PeBenito wrote:
> >>>> On 03/07/11 12:09, Guido Trentalancia wrote:
> >>>>> On Mon, 07/03/2011 at 08.56 -0500, Christopher J. PeBenito wrote:
> >>>>>> On 02/23/11 13:50, Guido Trentalancia wrote:
> >>>>> Also, what do you think about the idea of providing a make target (say
> >>>>> "make check") in refpolicy which runs some minimal checks on that for at
> >>>>> least the core processes ?
> >>>>
> >>>> I can't think of how that would work off the top of my head.  If you have ideas, I'd be happy to listen.  I'd prefer to not write a script that has all of the checking hard coded in it.
> >>>
> >>> It's just something very simple. A make target which runs ps axZ (as
> >>> sysadm) and compares a few very basic things:
> >>>
> >>> - if init has properly transitioned to its context (apparently at the
> >>> moment no one cares if it hasn't, which is quite worrying as everything
> >>> could run in kernel_t without showing any symptom or warning);
> >>> - for a few core modules (as long as they are compiled in the policy),
> >>> that they are running in the proper context: so for example if polkitd
> >>> is running in policykit_t context (ps axZ | grep polkitd | grep
> >>> policykit_t).
> >>>
> >>> Of course you can avoid hardcoding the keywords "polkitd" and
> >>> "policykit_d" as long as you can get that out of policykit.{te,fc} by
> >>> the means of some other form of regexp matching and string processing
> >>> (sed, awk) for example: something very simple, something very basic,
> >>> still quite useful to the inexperienced user.
> >>
> >> What you're describing is a big hardcoded script, which I'm trying to avoid.
> > 
> > More or less this what I meant:
> > 
> > check:
> > 	ps axZ | grep init | grep -q init_t || echo "FAIL: init has not
> > transitioned properly to its context"
> > 
> > and so on for the a few other basic first-line context checks.
> > 
> > If you don't like it, it doesn't matter. Any test needs at least to have
> > the reference results "hardcoded".
> 
> Actually, this is one of the reasons I created the sestatus tool (see
> sestatus -v): to help people determine certain the context of key files
> and processes.  It doesn't validate that the contexts are correct, but
> it makes it easy to find them.

The sestatus tool can be used for init only and not much more. But
that's fine. I can't see what's wrong with integrating that into a "make
check" target. Assume the end-user does not know anything about SELinux
(not even that there is a sestatus tool).

Next one could be dbus (if its module is enabled in the policy), so
something based on:

ps axZ | grep dbus-daemon | grep -q system_dbusd_t || echo "FAIL: dbus
daemon might be running in the wrong context"

This checks will all be one-line. They can be made a bit more robust,
but still one-line.

Regards,

Guido