[redhat-lspp] Posix Message Queues

Stephen Smalley sds at tycho.nsa.gov
Mon Aug 15 17:17:32 UTC 2005


On Mon, 2005-08-15 at 12:45 -0400, Janak Desai wrote:
> James Morris wrote:
> > What would the LSPP requirements for control over Posix message queues be?
> > 
> > 
> > - James
> 
>  From UDP perspective, both DAC and MAC protections are required for
> message queues. I believe SELinux already provides MAC so we are
> ok on that front. Intially we thought we would have to provide
> ACLS on ipc objects, but after consulting with atsec, we think
> that we will be ok with UNIX DAC, which is already provided.

To clarify, POSIX message queues were not in the mainline kernel when
SELinux (and LSM) was developed, and thus they were not considered
during SELinux or LSM development.  System V message queues were
considered, with appropriate LSM hooks defined and SELinux access
controls implemented for them, but that is not the same.  The POSIX
message queue implementation was merged into mainline well after LSM and
SELinux had already been merged.

Since the POSIX message queue implementation is based on a pseudo
filesystem interface, the SELinux inode permission checks may be
sufficient for providing MAC protection of POSIX mqueues.  A student who
spent the summer here did some investigation of POSIX mqueues.  He had
to enable labeling support for the mqueue pseudo filesystem (which is
now in the example policy and thus the rawhide policy), and wrote some
tests to perform POSIX mqueue operations and verify that the policy (on
the corresponding inodes in the pseudo filesystem) was enforced as
expected.  The real question is whether that is sufficient for LSPP.
Access control is only at the granularity of a queue, not per-message.

Note btw that even though we do have MAC for System V IPC, we do not
presently have interfaces for creating IPC objects with a particular
label, getting the label of an existing IPC object, or relabeling an
existing IPC object.  Not sure if that is needed for LSPP.  

-- 
Stephen Smalley
National Security Agency




More information about the redhat-lspp mailing list