On Wed, 2006-11-29 at 01:00 -0500, Paul Moore wrote: > I just took a quick look at the patch and I have to ask why you decided to > take the context from the xinetd config file instead of using > security_compute_create() as described in BZ #209379? As it stands I don't > think the current approach of taking the full SELinux context (TE and MLS > label) from the config file solves the problem we are interested in - > multi-level network services via xinetd.
Ok, if that's the problem I'm not sure why we want any changes to the
config. file. As I understand it from the above BZ, you have:
user_u:system_r:inetd_t
= xinetd is running as this
user_u:system_r:fingerd_exec_t
= in.fingerd on disk
user_u:system_r:fingerd_t
= in.fingerd when run normally from xinetd
user_u:system_r:unconfined_t:SystemLow-SystemHigh
= getpeercon()
user_u:system_r:fingerd_t:SystemLow-SystemHigh
= What we want the in.fingerd to be running in, with ML networking
So we need to take the getfilecon() and getpeercon() and combine them
somehow (the BZ says security_compute_create()[1]), and we might then
need to move to fgetfilecon() / fexecve() to close the race :(.
Is the above right? If not what piece(s) of information need to come
from the config. file?
[1] I tried a few different calls with security_compute_create, and
maybe I'm not using the right security class, but I can't get it to
combine the TE and MLS correctly.
--
James Antill <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
-- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
