On Sat, 27 Oct 2001, Andi Kleen wrote:
> On Sat, Oct 27, 2001 at 03:58:22PM +1000, James Morris wrote:
> >
> > I was hoping that skb->security could be reassigned as a void pointer
> > for use by LSM in 2.5, if LSM is accepted into the kernel.
>
> void pointer alone without any rules for freeing and reference counting
> (e.g. what to do with it on a skb_clone() or a skb_copy()) would not
> make too much sense. Getting that right would be probably ugly
> (similar to rusty's old abandoned ->cb attribute allocator)
>
This is a little different to skb field reservation. LSM is a general
kernel framework which allows different security models to be implemented
via a hook-based API.
It is up to specific implementations to implement a policy (if any) for
the skb security pointer. The LSM API provides a mechanism for this via
hooks which are called at important points in the lifecycle of an skb,
such as clone and copy as you mention.
The hook declarations and documentation may be viewed at:
http://sejanus.wirex.com:5555/anno/include/linux/security.h@xxxx?nav=index.html|src/.|src/include|src/include/linux
> >
> > This would be used by LSM modules for maintaining security attributes
> > between layers. Note that this may also be useful for Freeswan, as it
> > should be possible now to implement ipsec as an LSM module.
>
> Could you give a more detailed scenario what it would be needed for?
>
One scenario would be the use of packet labeling to implement mandatory
access controls for IP networking.
Labeling and access decisions may need to be made based on security
conditions at various layers of the stack at specific points in time.
For example, an outgoing packet might be labeled with the security
attributes of the sending process and/or the object being transmitted.
These attributes would need to be propagated between layers, and
maintained throughout the life of the packet within the system.
The latter is particularly critical in supporting security policy change,
which may involve re/invalidating security attributes associated with
packets.
This scenario might also be extended to security processing performed in
hardware, so there is a possibility of interelated labeling and access
control decisions at every layer.
(I'd prefer to show you some code, but I'm not aware of any projects of
this nature which are ready for public consumption yet).
Note that if someone was to come up with an acceptable skb field
reservation scheme, then LSM would probably be able to make use of it.
- James
--
James Morris
<jmorris@xxxxxxxxxxxxxxxx>
|