Re: New stacker performance results

From: serue@private
Date: Tue May 24 2005 - 14:56:13 PDT

Quoting Stephen Smalley (sds@private):
> On Mon, 2005-05-23 at 07:49 -0400, Serge E. Hallyn wrote:
> > Oh, as of very recently, I'm actually able to volunteer to do that :)
> > So I'll happily update whatever I can find, though I'm not sure where
> > all the patches should go and what all needs to be patched.  Clearly
> > selinuxfs and procutils.  I'll dig around.
> s/selinuxfs/libselinux, right?

Oops, yes.

> The largest concern is backward compatibility, especially since FC3,
> FC4, and RHEL4 will all have shipped with userlands that assume
> that /proc/self/attr is the exclusive domain of SELinux.  Or you'd have
> to have a coordinated update to kernel and libselinux (and procps and
> initscripts and whatever else).

We should be able to work around that in two ways.  First, a boot time
argument to stacker could disable the new functionality.

Second, stacker could still know about selinux.  In general, modules
read/write data as

module_name: data

But if stacker reads data not in that format from userspace, it sends it
to selinux.  Stacker could write selinux's procattr info without a
leading "selinux: " if (a) a boot time arg tells it to, (b) a sysfs
directive tells it to, or (c) it has read data from selinux without the
leading "selinux: " before.  I wonder whether, in case (c), we would
generally write to a procattr file before reading one...

> > (I had been considering just leaving procattr unaddressed, but was
> > told last friday that another module will in fact be able to make
> > good use of it)
> An open source module?

Yes, I expect it to be GPL.

> Not clear that any of these other than seclvl should be using LSM;
> discussion on lkml for IMA suggests otherwise.  No obvious value in

There are two reasons I'm still uncertain:

First, another very respected kernel developer's private auditfs
feedback included asking why the hooks which were next to LSM hooks
weren't using LSM.  The answer in this case was that audit must always
run before an LSM.  But that sounds to me like the issue for the ima
module itself is still open for debate.

Second, the other modules are in fact authorization modules, and so
could not use hooks which existed only for measurement.

Assuming the tpm authorization module was going to be an LSM, are
there reasons why it would not be useful with selinux?  What about

> stacking seclvl with SELinux vs. configuring SELinux policy to impose
> equivalent restrictions (but in a saner manner, since you can use policy
> on a per-process level to deal with the exception cases where you have
> to allow violations of the seclvl restrictions)?

Yes, I definately see your point about seclvl+selinux.


This archive was generated by hypermail 2.1.3 : Tue May 24 2005 - 14:57:23 PDT