ipc security context

ipc security context

[Ondrej Oprala]

Hi,
is it possible to get/set a security context per separate IPC objects?
As far as my googling got me, it seems IPCs are the same context
as process creation, so I'm guessing I should probably be able
to get some info about a shared memory segment for example, by passing
lpid to getpidcon. Are my assumptions correct or am I completely off the 
chart?
I'd be very thankful for any clarification.

Have a nice day,
Ondrej

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: ipc security context

[Stephen Smalley]

On 04/11/2013 08:31 AM, Ondrej Oprala wrote:
> Hi,
> is it possible to get/set a security context per separate IPC objects?
> As far as my googling got me, it seems IPCs are the same context
> as process creation, so I'm guessing I should probably be able
> to get some info about a shared memory segment for example, by passing
> lpid to getpidcon. Are my assumptions correct or am I completely off the
> chart?
> I'd be very thankful for any clarification.

If you truly need to programmatically get the security context of an IPC 
object, I'd suggest defining new command values for the *ctl() functions 
that copy out the security context of the IPC object.  That's a kernel 
change of course.

If you just want to see the security contexts of some IPC objects, then 
you can likely just turn on syscall audit and define some audit filters 
to trigger collection and auditing of the ipc object information, 
including its security context.  Or you might try defining auditallow 
rules for the relevant domain(s) with the ipc object security classes in 
your policy.

Looking up the security context from the pid may work in some cases, but 
won't be reliable.  In the case of shm, I think you'd want cpid rather 
than lpid, but even that won't guarantee it is still the same.
It would be better to have real APIs for getting the security context.









--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

IPC security context

[andy.suchoski]

Hello,

Is there any way to see the security context of semaphores, message queues and shared memory areas? I would have expected to see a "-Z" option on the ipcs command since this command reports DAC information.

Also, are there any library routines to access the security attributes of IPC objects?

Thanks.

- Andy Suchoski

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: IPC security context

[Stephen Smalley]

On Thu, 2006-09-07 at 19:52 +0000, andy.suchoski@comcast.net wrote:
> Hello,
> 
> Is there any way to see the security context of semaphores, message queues and shared memory areas? I would have expected to see a "-Z" option on the ipcs command since this command reports DAC information.
> 
> Also, are there any library routines to access the security attributes of IPC objects?

Not presently, no.  That support was lost when the SELinux API had to be
overhauled for Linux 2.6.  To re-add, we would need a specific
application that required such support.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: IPC security context

[Steve G]

>To re-add, we would need a specific application that required such support.

Would ipcs be that app?  I would think that you want to be able to display IPC
labels to check up on things to make sure nothing unexpected is being allowed to
happen.

-Steve

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: IPC security context

[Russell Coker]

On Friday 08 September 2006 07:05, Steve G <linux_4ever@yahoo.com> wrote:
> >To re-add, we would need a specific application that required such
> > support.
>
> Would ipcs be that app?

I believe so.

I am currently working on writing policy for some proprietary software that 
uses a lot of shared memory and semaphores.  The inability to display 
contexts through ipcs is a significant obstacle for me in this work.

-- 
http://etbe.blogspot.com/          My Blog
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: IPC security context

[Stephen Smalley]

On Fri, 2006-09-08 at 10:05 +1000, Russell Coker wrote:
> On Friday 08 September 2006 07:05, Steve G <linux_4ever@yahoo.com> wrote:
> > >To re-add, we would need a specific application that required such
> > > support.
> >
> > Would ipcs be that app?
> 
> I believe so.
> 
> I am currently working on writing policy for some proprietary software that 
> uses a lot of shared memory and semaphores.  The inability to display 
> contexts through ipcs is a significant obstacle for me in this work.

I'm a bit skeptical that ipcs itself is sufficient motivation, as one
can always make use of audit configuration (whether via auditallow in
policy or auditctl with the enhanced syscall audit that includes
contexts) to see the object contexts in the audit logs for development
purposes.  The motivating application would have to be software that is
actually using the IPC objects and needs to get or set the context of
those objects, and at least one such application would likely need to be
open source to serve as a compelling example for upstream.  See the
earlier discussion about adding a /proc/self/attr/ipccreate node on this
list and in redhat bug 197114; the same issue applies there.

Note that I'm not the obstacle here - I would be happy to see the entire
original SELinux API revived (in a different form that is acceptable
upstream, naturally, but equivalent in functionality to the old API),
but at the time we were forced to refactor the SELinux API (upon removal
of sys_security in 2.5), we were told that we needed real examples of
users for any interfaces we added.  Hence, we limited ourselves to the
process, file, and security interfaces, then added other interfaces as
needed (e.g. getpeercon).

If we want to go down this road, I think we need two things:
1) A concrete proposal on what such interfaces should look like, taking
into consideration the factors that led to the rejection of the original
API.  Offhand, I'd think that the approach most in line with the
existing IPC interfaces would be a new cmd value for msgctl, semctl, and
shmctl that gets the context, calling into the security module to obtain
the value, modeled on getpeercon.
2) A real user of such interfaces to demonstrate that they will be used
and that we at least have some evidence that the interface is correct
for the intended usage and won't have to immediately change when a real
user manifests.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.