Klaus Weidner wrote:
> 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.
That makes sense to me.
>
>
>
>>### 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.
As far as I can tell it doesn't work with the latest mls policy. I
removed the lspp policy module from my system and cleaned up everything
I could think of and I get these errors in /var/log/secure when I try
to log in in enforcing mode:
Dec 5 18:33:19 kipper sshd[2100]: pam_namespace(sshd:session): Set namespace
for directory /home/ljk
Dec 5 18:33:19 kipper sshd[2100]: pam_namespace(sshd:session): member context
returned by policy staff_u:object_r:staff_home_dir_t:SystemLow-SystemHigh
Dec 5 18:33:19 kipper sshd[2100]: pam_namespace(sshd:session): poly_name
staff_u:object_r:staff_home_dir_t:SystemLow-SystemHigh_ljk
Dec 5 18:33:19 kipper sshd[2100]: pam_namespace(sshd:session): Inst ctxt
staff_u:object_r:staff_home_dir_t:SystemLow-SystemHigh Orig ctxt
staff_u:object_r:staff_home_dir_t:SystemLow-SystemHigh
Dec 5 18:33:19 kipper sshd[2100]: pam_namespace(sshd:session): instance_dir
/home/home.inst/staff_u:object_r:staff_home_dir_t:SystemLow-SystemHigh_ljk
Dec 5 18:33:19 kipper sshd[2100]: pam_namespace(sshd:session): Error setting
context of
/home/home.inst/staff_u:object_r:staff_home_dir_t:SystemLow-SystemHigh_ljk to
staff_u:object_r:staff_home_dir_t:SystemLow-SystemHigh
Dec 5 18:33:19 kipper sshd[2100]: pam_namespace(sshd:session): Error mounting
/home/home.inst/staff_u:object_r:staff_home_dir_t:SystemLow-SystemHigh_ljk on
/home/ljk, Permission denied
Dec 5 18:33:19 kipper sshd[2100]: pam_namespace(sshd:session): namespace setup
failed for pid 2100
I get these AVC:
time->Tue Dec 5 18:33:19 2006
type=SYSCALL msg=audit(1165361599.749:473): arch=40000003 syscall=228 success=no
exit=-13 a0=6 a1=e0600b a2=8637da0 a3=32 items=0 ppid=2095 pid=2100 auid=501
uid=0 gid=501 euid=0 suid=0 fsuid=0 egid=501 sgid=501 fsgid=501 tty=(none)
comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s15:c0.c1023
key=(null)
type=AVC msg=audit(1165361599.749:473): avc: denied { relabelfrom } for
pid=2100 comm="sshd"
name="staff_u:object_r:staff_home_dir_t:SystemLow-SystemHigh_ljk" dev=dm-1
ino=5013507 scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
----
time->Tue Dec 5 18:33:19 2006
type=AVC_PATH msg=audit(1165361599.750:474): path="/home/ljk"
type=SYSCALL msg=audit(1165361599.750:474): arch=40000003 syscall=21 success=no
exit=-13 a0=86384d8 a1=864a208 a2=0 a3=1000 items=0 ppid=2095 pid=2100 auid=501
uid=0 gid=501 euid=0 suid=0 fsuid=0 egid=501 sgid=501 fsgid=501 tty=(none)
comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s15:c0.c1023
key=(null)
type=AVC msg=audit(1165361599.750:474): avc: denied { mounton } for pid=2100
comm="sshd" name="ljk" dev=dm-1 ino=3145729
scontext=system_u:system_r:sshd_t:s0-s15:c0.c1023
tcontext=staff_u:object_r:staff_home_dir_t:s0-s15:c0.c1023 tclass=dir
These are slightly different from the ones I get when the lspp policy
module is loaded (which also doesn't work). I haven't tried stripping
down the lspp policy module to just include things like the
files_polyinstantiate_all(sshd_t) line to see if that helps.
If its working for you then please let me know how. Perhaps I didn't
clean up enough or there's just something wrong with my system.
Thanks,
-- ljk
>
>
>>### 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
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
