All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Valdis.Kletnieks@vt.edu
Cc: Park Lee <parklee_sel@yahoo.com>,
	Casey Schaufler <casey@schaufler-ca.com>,
	SELinux <SELinux@tycho.nsa.gov>
Subject: Re: Question about integration of IPsec with SELinux?
Date: Sun, 12 Jun 2005 16:20:38 +0100	[thread overview]
Message-ID: <20050612152038.GC31033@lkcl.net> (raw)
In-Reply-To: <200506121239.j5CCdksZ009355@turing-police.cc.vt.edu>

On Sun, Jun 12, 2005 at 08:39:45AM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Sun, 12 Jun 2005 12:44:21 BST, Luke Kenneth Casson Leighton said:
> 
> >  btw i should also raise - again - the wisdom of only utilising
> >  a 32-bit security descriptor in a networked environment.
> 
> Should be sufficient in an IPv4 environment, since it's only identifying
> the other end.  I'm not awake enough yet

 ha!  you too? :)

> - does IPsec on the IPv6 side only
> carry 32-bit identifiers too? I'd consider *that* a design whoops...
 
 the underlying SIDs of selinux are 32-bit.

 [i do not know about IPsec or IPv6.]

 NT security descriptors are variable-length in multiples of 32-bit -
 anything up to a maximum of... [*guess*] 6x32-bit.

 there are special well-known security descriptors e.g. iirc correctly:
 S-1-0 is "world".

 even a workstation has its own SID "prefix", such that local users and
 local services running on that workstation are uniquely - world-wide -
 identifiable.

 [side-note: the only thing stopping NT 4.0 security from being
 expandable world-wide was the use of a NetBIOS naming scheme
 for name resolution.  if microsoft had obeyed the rfc1001
 and rfc1002 specifications, developed back by IBM somewhere
 in the 1980s iirc, then it would have been possible to map
 MS's NetBIOS implementation properly onto DNS, and they would
 have been off on a winner.  anyway...]


 ... when you only have 32-bit SIDs, as you do in selinux,
 how do you merge two departments or two corporations together,
 _after_ their MLS security has been independently developed?



> >  only 32-bit means that if you want to merge or join two secure
> >  environments together, well.... you basically can't: you have a clash
> >  of 32-bit SIDs.
> 
> Oh - the old "merge 2 1918 spaces" problem.. ;)  I suppose suggesting
> creative use of a NAT and RFC3489 would get blunt objects heaved in my direction. ;)

 well... maybe and maybe not :)

 as long as you are happy to put up with the selinux-sid-NAT table
 expanding out to near-epic proportions...

 ... but it's not _as_ daft as it sounds [at least to me, who came up
 with the SID<->uid/gid-Resolution system for samba]

 just... whatever you do, don't for one second be as stupid
 as the present samba team leadership, and imagine that it's
 okay to do "one-to-many" or "many-to-one" mappings in the
 selinux-sid-NAT tables...

 but the _better_ solution is to have a prefix - on a per-workstation
 basis AND also on a per-... ummm....

 what's a top-level MLS policy called?

 with the word "domain" taken up, which from the "nt domain"
 perspective i _would_ recommend the use of if it wasn't
 already used by selinux "domains"...

 what name should be given to a per-group-of-machines-and-users MLS
 policy?



> >  with NT / VAX-VMS style security descriptors (comprising 4of 32-bit
> >  "SIDs" for a domain and a 32-bit "RID" - relative ID) you can at least
> >  start creating inter-domain trust relationships.
> 
> Once you've established a secure connection to an identified host, there's
> nothing stopping you from passing more info down the pipe if the IP 4-tuple
> isn't sufficient to provide all the info needed..
 
 ah - but how do you say "a local [to me] user when they log
 in to the remote domain must be allowed to run program X"
 when the number for the selinux SID on that remote domain
 utilises the same SID number - for a different purpose?

 are you intending to add in a prefix of some kind, just like
 there is in NT / VAX-VMS security?

> >  now's the opportunity to ensure that MLS will be future-proof.
> > 
> >  are there any other alternate solutions to merging two MLS secure
> >  environments together?
> 
> I think a useful rephrasing is:
> 
> What information needs to be passed when opening an inter-domain trusted
> connection, that isn't already available in the IPSec headers?

 could you possibly help out here by clarifying that we are talking
 about the same thing?

 i don't see what the relevance of the IPsec headers are.

 are you intending the IPsec headers to be the equivalent of the NT /
 VAX-VMS domain "prefix"?

 is there any documentation online that i can read/refer to that will
 help me out, here?

 ta,

 l.


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

  reply	other threads:[~2005-06-12 15:20 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-11 10:38 Question about integration of IPsec with SELinux? Park Lee
2005-06-11 17:27 ` Casey Schaufler
2005-06-11 18:45   ` Park Lee
2005-06-11 19:18     ` Valdis.Kletnieks
2005-06-11 19:49       ` Casey Schaufler
2005-06-12  2:16         ` Park Lee
2005-06-12 11:44           ` Luke Kenneth Casson Leighton
2005-06-12 12:39             ` Valdis.Kletnieks
2005-06-12 15:20               ` Luke Kenneth Casson Leighton [this message]
2005-06-12 19:18                 ` Valdis.Kletnieks
2005-06-12 20:25                   ` Luke Kenneth Casson Leighton
2005-06-12 20:30                     ` Valdis.Kletnieks
2005-06-12 20:52                     ` Luke Kenneth Casson Leighton
2005-06-12 21:45                       ` Valdis.Kletnieks
2005-06-13 13:00                     ` Stephen Smalley
2005-06-13 21:16                       ` Luke Kenneth Casson Leighton
2005-06-14 13:21                         ` Stephen Smalley
2005-06-14 14:31                           ` Trent Jaeger
2005-06-15 22:04                             ` Luke Kenneth Casson Leighton
2005-06-12 23:32                   ` Casey Schaufler
2005-06-13  0:21                     ` Valdis.Kletnieks
2005-06-13 10:01                     ` Luke Kenneth Casson Leighton
2005-06-13 13:37                       ` Valdis.Kletnieks
2005-06-13 14:10                       ` Casey Schaufler
2005-06-13 12:49                 ` Stephen Smalley
2005-06-13 21:17                   ` Luke Kenneth Casson Leighton
2005-06-13 12:37             ` Stephen Smalley
2005-06-13 21:19               ` Luke Kenneth Casson Leighton
2005-06-12 12:34           ` Valdis.Kletnieks
2005-06-12 15:25             ` Luke Kenneth Casson Leighton
2005-06-12 16:16             ` Park Lee
2005-06-12 17:50           ` Casey Schaufler
2005-06-12 16:34   ` Park Lee
2005-06-12 17:02   ` Park Lee
2005-06-12 17:46     ` Casey Schaufler
     [not found] <20050613213951.GB17617@lkcl.net>
2005-06-13 22:03 ` Casey Schaufler
2005-06-13 22:44   ` Luke Kenneth Casson Leighton
2005-06-16 16:01   ` Brian T. Sniffen
  -- strict thread matches above, loose matches on Subject: below --
2005-06-14 18:11 Park Lee
2005-06-14 21:23 ` Casey Schaufler
2005-06-15  1:20   ` Park Lee
2005-06-15  3:00     ` Casey Schaufler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050612152038.GC31033@lkcl.net \
    --to=lkcl@lkcl.net \
    --cc=SELinux@tycho.nsa.gov \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=casey@schaufler-ca.com \
    --cc=parklee_sel@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.