Re: 2001_05_09 patch against 2.4.4

pollardat_private

---------  Received message begins Here  ---------

Chris Wright <chrisat_private>:
> * Chris Evans (chrisat_private) wrote:
> > 
> > > The current scheme is to control access to the kernel's core data
> > > structures.  Some of this requires hooks in syscalls, other places this
> > > does not (the whole networking hook system will not be near the single
> > > network syscall, from what I think Chris W. has in mind.)
> > 
> > I think the most important "object" to hook in the networking land is the
> > "network interface". Quick cheesy example:
> > - eth0: labelled as low security
> > - slip0: labelled as high security
> > /etc/very/secret: labelled as sensitive, high security
> > process pid 100: has /etc/very/secret open, marked as sensitive
> > process pid 100 does socket()
> > process pid 100 tries to bind to IP address owned by eth0 => EPERM!!
> 
> I agree the device is one piece that we need to watch, but i'm not sure that
> it is the most important.  Look at packet filter firewall rules, they are
> largely about complete tuples not just devices.  In your example, eth0 may
> need finer granularity than low security.  Perhaps it is fine to talk out
> eth0 to mysercurehost.com on port 22 using tcp even if I have
> /etc/very/secret open.  I'd like to be able to support tcp connect/accept
> and udp send/recv to/from host:port via device (howz that for non-sense? ;-)

Nope - very reasonable. It calls for IPSec layers on TCP, and CIPSO like
identification as well. The packet filter firewall rules appear to be acting
in the place of IPSec.

I would like even more integration....

local user (running secret on host W) attempts to connect to host X.

1. capability test locally determines that user is allowed network access...

2. MLS combines access request with security label (secret) and passed to
   IPSec.

3. IPSec security association (SA) determines that encryptions of session
   (or packet) is mandatory - policy decision between the local facility
   and the remote facility containing X (and the requirements of the local
   security label and encryption negotiation between W and X...).

4. Remote facility decrypts (based on local SA) examines security
   identification and extended security header for compatable translation of
   of label (passed from W).

5. User identification (contained in extended header) matched to local user
   on X.

6. MLS determines if user (on W) is authorized the label (translated from
   host W label).

7. connection between user on host W and service (on host X) established.

The key is that the network interface may operate at multiple levels depending
on the host-host connection. Protection is identified by the IPSec layer
to determine the amount of protection required.

This also permits the unencrypted connection if it is reasonable (host
W and X are both on internally controled networks AND under the same security
policy AND....).

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollardat_private

Any opinions expressed are solely my own.

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module