[redhat-lspp] Posix Message Queues

[Janak Desai]

Stephen Smalley wrote:
> 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.
> 

Thanks Stephen for context and clarification. I had just done a quick
code check to see if MAC check is performed when POSIX queues are accessed.
As far as the access control granularity, my understanding is that the
granularity at the level of a queue (and not message) is sufficient
since processes cannot exchange information with individual messages
without going through a queue. So treating queues (and not messages
as LSPP "named objects" is sufficient. SecureWare CMW, which was
evaluated under the older B1 standard, implemented MAC access checks on
queues and not messages, so I think we are ok but we will double check
this with our evaluators.

> 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.  
> 

LSPP doesn't require such interfaces. It just says that attributes
should be associated with named objects. The only problem I see with
lack of such interfaces is that the test setup for testing MAC on ipc
objects may get a little trickier, but strictly from LSPP I don't
think such interfaces are required.

-Janak