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 digsig? > 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. thanks, -serge
This archive was generated by hypermail 2.1.3 : Tue May 24 2005 - 14:57:23 PDT