From: guido@trentalancia.com (Guido Trentalancia) Date: Wed, 09 Mar 2011 16:34:33 +0100 Subject: [refpolicy] run/build-time sanity checks In-Reply-To: <201103100159.00445.russell@coker.com.au> References: <1297836836.3205.56.camel@tesla.lan> <1299681703.2948.42.camel@tesla.lan> <201103100159.00445.russell@coker.com.au> Message-ID: <1299684873.2948.73.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Thu, 10/03/2011 at 01.59 +1100, Russell Coker wrote: > On Thu, 10 Mar 2011, Guido Trentalancia wrote: > > > For domain transitions it is mostly a matter of having a cron job or > > > nagios entry that searches for wrong entries such as processes in > > > kernel_t or initrc_t. > > > > What's wrong with just a "make check" target in refpolicy ? > > It just doesn't work. > > The main problem I've found in transitions not working is binaries getting > renamed, which "make check" can never find. But do you mean application or daemon binaries ? That would be classified as a labeling problem. There are infinite degrees of freedom with the naming of executables (not necessary "binaries"). I suppose that the reference policy targets a reference system. And the reference system is an upstream system. And upstream systems should have no degrees of freedom on the naming of executables. Even if the reference system did not exactly coincide with an upstream system, the reference system would still be unique by definition (I don't know exactly, maybe it's a system being run at Tresys). > The next issue is application misconfiguration, such as an xdm program not > having the correct PAM configuration, again it's not something that you can > check through policy. That's not a problem with refpolicy I think. That's a local misconfiguration (or even intentional). At least initially, such a "make check" should not target any possible SELinux configuration or misconfiguration. I think that's a different issue. That would fall under another class of testing. That would be an overall testing of the effectiveness of specific_custom_linux_system/SELinux/refpolicy for the end-user. Very useful, perhaps also complex and expensive but in any case a different thing in my imagination. > > There is major limitation with this: reboot and/or restarting of > > services required. In the simple solution that I was thinking of, this > > limitation could be documented and printed out: echo $limitation ; sleep > > 10 ; carry out basic sanity checks. > > Rebooting a VM is no big deal at all. It's something that can be done by a > cron job. > > Also I'd like to automate the process of an X login and running some > applications in KDE and GNOME sessions. Any suggestions of how to do this > would be appreciated. Through xdmcp and/or x11 ports ? But I suppose a bit of compiled code (ideally C) would be required here. The applications could then be started automatically through the session manager (e.g. gnome-session configuration) ? Then after a few seconds the main script checks that everything is running in the proper context. Finally it kills everything and creates the report (or iterates for other configurations). Regards, Guido