linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: richard offer <offer@sgi.com>
To: Stephen Smalley <sds@epoch.ncsc.mil>
Cc: Andreas Gruenbacher <ag@bestbits.at>,
	Linus Torvalds <torvalds@transmeta.com>,
	lsm <linux-security-module@wirex.com>, "Ted Ts'o" <tytso@mit.edu>,
	lkml <linux-kernel@vger.kernel.org>,
	Stephen Tweedie <sct@redhat.com>
Subject: Re: [RFC][PATCH] Extended Attributes for Security Modules
Date: Wed, 16 Apr 2003 15:02:21 -0700	[thread overview]
Message-ID: <743940000.1050530541@changeling.engr.sgi.com> (raw)
In-Reply-To: <1050500841.2682.62.camel@moss-huskers.epoch.ncsc.mil>





* frm sds@epoch.ncsc.mil "04/16/03 09:47:22 -0400" | sed '1,$s/^/* /'
* 
* Thanks for your comments.  It occurred to me after I sent my initial
* reply that you might be thinking of a scenario where you have two
* different security modules for two different environments, and you
* switch back and forth between them depending on what environment you are
* working in.  

I'm not sure what I was thinking, I think I was thinking about smaller
modules, say capabilities and openwall or alternatively a reluctance to
remove things that "belong" to other people... 

If you attach a capability attribibute to a file under the capability
module, what happens when you use SELinux ? Under your scheme, you'd remove
the capability and write a combined attribute that included SELinux and and
if needed the capability. 

Under my scheme, the capability attribute would be left alone, SELinux
would add its own, and then as its the primary module would decide whether
to use the existing capability attribute or its own "combined" attribute.
The important thing is that if you ever decide to reboot a pure capability
system that you don't have to refigure all your attributes (although you
could/should).

Extended attributes are still relatively rare that people forget to record
them when replacing a file (I do that all the time under Trusted Irix),
under your scheme they would have to record every attribute on the system
before loading a module if they every wanted to return to its prior state.
If you forgot to do it just once the consequences could be nasty.

With separate attributes, its easy to write a tool to "de-dte" a system by
removing all the DTE attributes and know that nothing else will change. But
that would be a direct user action, not an unforseen side effect.

I can see your reasons for the single attribute (known quantity for
production systems), but think its better at this stage to experiment with
multiple attributes and see how people use them before forcing everyone to
a single standard. It allows small steps rather than force everyone to make
a single large one.

* Stephen Smalley <sds@epoch.ncsc.mil>
* National Security Agency

richard.

-- 
-----------------------------------------------------------------------
Richard Offer                     Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________


  reply	other threads:[~2003-04-16 21:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-10 12:06 [RFC][PATCH] Extended Attributes for Security Modules Stephen Smalley
2003-04-13 22:57 ` Andreas Gruenbacher
2003-04-15 13:41   ` Stephen Smalley
2003-04-15 16:58     ` richard offer
2003-04-15 18:19       ` Stephen Smalley
2003-04-16 13:47       ` Stephen Smalley
2003-04-16 22:02         ` richard offer [this message]
2003-04-17  4:24           ` Stephen Smalley
2003-04-17 20:30             ` Chris Wright
2003-04-17 20:53               ` richard offer
2003-04-18  1:07                 ` Chris Wright
  -- strict thread matches above, loose matches on Subject: below --
2003-04-15 18:33 Chuck Ebbert
2003-04-15 18:56 ` Chris Wright
2003-04-08 20:26 Stephen Smalley

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=743940000.1050530541@changeling.engr.sgi.com \
    --to=offer@sgi.com \
    --cc=ag@bestbits.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@wirex.com \
    --cc=sct@redhat.com \
    --cc=sds@epoch.ncsc.mil \
    --cc=torvalds@transmeta.com \
    --cc=tytso@mit.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).