Hi!
Does anyone here know of work being done in order to implement secure IPC for
Linux?
Anyone that have some ideas for how this could be done?
Best regards,
Kristian S?rensen.
--
Kristian S?rensen
The Umbrella Project -- Security for Consumer Electronics
Linnovative -- http://www.linnovative.dk
[email protected] -- +45 2972 3816
Kristian S?rensen wrote:
> Hi!
>
> Does anyone here know of work being done in order to implement secure IPC for
> Linux?
>
> Anyone that have some ideas for how this could be done?
>
>
> Best regards,
> Kristian S?rensen.
>
>
Linux uses the System V IPC, maybe a switch to a IPC like the one used in
the gnu match microkernel is more secure and comfortable. The port concept
is very interesting, becuase it has access rights.
Matthias-Christian Ott
On Mon, 9 May 2005, Kristian S?rensen wrote:
> Does anyone here know of work being done in order to implement secure IPC for
> Linux?
What do you mean by secure IPC?
- James
--
James Morris
<[email protected]>
On Monday 09 May 2005 17:00, James Morris wrote:
> On Mon, 9 May 2005, Kristian S?rensen wrote:
> > Does anyone here know of work being done in order to implement secure IPC
> > for Linux?
>
> What do you mean by secure IPC?
As I understand it, presently the memory for the message queue is shared based
on user and group ownership of the process. By "secure IPC" is meaning a
security mechanism that provides a more fine granularity of specifying who
are allowed to send (or receive) messages... and maby also a way to resolve
the question of "Can I trust the message I received?"
--
Kristian S?rensen
The Umbrella Project -- Security for Consumer Electronics
Linnovative -- http://www.linnovative.dk
[email protected] -- +45 2972 3816
* Kristian S?rensen ([email protected]) wrote:
> On Monday 09 May 2005 17:00, James Morris wrote:
> > On Mon, 9 May 2005, Kristian S?rensen wrote:
> > > Does anyone here know of work being done in order to implement secure IPC
> > > for Linux?
> >
> > What do you mean by secure IPC?
> As I understand it, presently the memory for the message queue is shared based
> on user and group ownership of the process. By "secure IPC" is meaning a
> security mechanism that provides a more fine granularity of specifying who
> are allowed to send (or receive) messages... and maby also a way to resolve
> the question of "Can I trust the message I received?"
There's hooks to handle this. See the security blob in struct
kern_ipc_perm (which is embedded in the various SysV ipc structures),
and the associated security hooks to manage the labels and provide
access control to the ipc objects. Also, AF_UNIX is handled with
security hooks (see the unix_ hooks). From that point forward, it's up
to you to label and enforce access control. SELinux has some supoort
for this type of access control.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Kristian S?rensen wrote:
> By "secure IPC" is meaning a
> security mechanism that provides a more fine granularity of specifying who
> are allowed to send (or receive) messages... and maby also a way to resolve
> the question of "Can I trust the message I received?"
How about unix sockets?
--you can have sockets in the filesystem namespace with regular file
permissions to control who is allowed to send messages to particular
addresses
--you can authenticate who is sending the message using SCM_CREDENTIALS
--nobody else can eavesdrop on the messages
Chris
Kristian S?rensen wrote:
> On Monday 09 May 2005 17:00, James Morris wrote:
>
>>On Mon, 9 May 2005, Kristian S?rensen wrote:
>>
>>>Does anyone here know of work being done in order to implement secure IPC
>>>for Linux?
>>
>>What do you mean by secure IPC?
>
> As I understand it, presently the memory for the message queue is shared based
> on user and group ownership of the process. By "secure IPC" is meaning a
> security mechanism that provides a more fine granularity of specifying who
> are allowed to send (or receive) messages... and maby also a way to resolve
> the question of "Can I trust the message I received?"
>
>
I think the gnumach (sorry for the typo in my last e-mail) concept, fixes
the sending and receiving permission problem. See the gnumach
documentation and source code.
Matthias-Christian Ott
On Monday 09 May 2005 19:54, Chris Friesen wrote:
> Kristian S?rensen wrote:
> > By "secure IPC" is meaning a
> > security mechanism that provides a more fine granularity of specifying
> > who are allowed to send (or receive) messages... and maby also a way to
> > resolve the question of "Can I trust the message I received?"
>
> How about unix sockets?
> --you can have sockets in the filesystem namespace with regular file
> permissions to control who is allowed to send messages to particular
> addresses
This is the same problem: Basing access control on user and group is not
enough - especially as the root-user can overrule any access control
specified by the normal DAC file attributes.
> --you can authenticate who is sending the message using SCM_CREDENTIALS
I guess this poses the same problem as above?
KS
--
Kristian S?rensen
The Umbrella Project -- Security for Consumer Electronics
Linnovative -- http://www.linnovative.dk
[email protected] -- +45 2972 3816
* Kristian S?rensen ([email protected]) wrote:
> On Monday 09 May 2005 19:54, Chris Friesen wrote:
> > How about unix sockets?
> > --you can have sockets in the filesystem namespace with regular file
> > permissions to control who is allowed to send messages to particular
> > addresses
> This is the same problem: Basing access control on user and group is not
> enough - especially as the root-user can overrule any access control
> specified by the normal DAC file attributes.
If you want the application involved/aware, you can still use finer
grained credentials, have a look at getpeersec.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Mon, 9 May 2005, Kristian S?rensen wrote:
> On Monday 09 May 2005 19:54, Chris Friesen wrote:
> > Kristian S?rensen wrote:
> > > By "secure IPC" is meaning a
> > > security mechanism that provides a more fine granularity of specifying
> > > who are allowed to send (or receive) messages... and maby also a way to
> > > resolve the question of "Can I trust the message I received?"
> >
> > How about unix sockets?
> > --you can have sockets in the filesystem namespace with regular file
> > permissions to control who is allowed to send messages to particular
> > addresses
> This is the same problem: Basing access control on user and group is not
> enough - especially as the root-user can overrule any access control
> specified by the normal DAC file attributes.
You want MAC, in other words.
SELinux probably does what you want with fine grained MAC for Unix domain
networking and SO_PEERSEC for peer authentication.
- James
--
James Morris
<[email protected]>