On Tue, Dec 05, 2006 at 02:58:54PM -0500, Linda Knippers wrote:
> The current kickstart script installs an LSPP policy module that
> includes things that look like bug fixes to the mls policy. I
> think the file has become out of date with the updates that Dan
> has been making to the mls policy so do we need this anymore?
The original plan for the LSPP policy had been to support settings needed
for compliance with the protection profile which would be inappropriate
for general use, and to provide a way for admins to tune such settings
without having to rebuild the full policy (which would be beyond the
scope of acceptable modifications to the evaluated config).
I had abused this policy file to include some additional policy to make
features work that didn't with the current shipped policy, and I fully
agree that anything that's generally useful should go into the general
policy. Sorry, I should have been more active in communicating the
changes back to Dan and the other SELinux developers.
> If there are policy bugs I'd really like to see them fixed in
> one place and Dan seems to be doing a great job of generating
> policy rpms. Right now having a separate policy module means
> our testing is out of sync. We might need an lspp policy post-RHEL5
> GA but is there a reason we need it now?
I think the module is still useful (see comments below) but should be
stripped down to the items which need to stay configurable or aren't
appropriate for the default policy.
> # Audit setting of security relevant process attributes
> # These settings are OPTIONAL
> auditallow domain self:process setcurrent;
> auditallow domain self:process setexec;
> auditallow domain self:process setfscreate;
> #auditallow domain self:process setsocketcreate; # FIXME
> #auditallow domain self:process setipccreate; # FIXME
For LSPP compliance, we need audit capability for operations that change
security attributes or default settings such as these. Admins are free
to turn these off if they don't want this audit, but the system needs to
be capable to do so. If these auditallow entries were to go into the
default policy, they should be controlled by booleans, but I think these
are appropriate for the LSPP module since most users won't care about
them.
> ### Relabeling printer devices
> allow secadm_t printer_device_t:chr_file {getattr relabelfrom relabelto};
This is a bugfix, and if it's not needed anymore it should be removed.
> ### Polyinstantiation support
> files_poly(tmp_t)
[...]
> type_member staff_t staff_home_dir_t:dir staff_home_t;
[...]
> files_polyinstantiate_all(sshd_t)
If the default policy supports working polyinstantiation, these are
redundant, but I think polyinstantiation is sufficiently complex to need
local customization. I'll need to try using current policy to see if this
is still necessary.
> ### additional polyinst workarounds
> ### (FIXME, should these be fixed in refpolicy?)
The rest of the items are workarounds, and I agree that they should be
merged into the regular policy (most probably are there already).
-Klaus
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
