public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Andi Kleen <andi@firstfloor.org>, James Morris <jmorris@namei.org>
Cc: linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: AppArmor FAQ
Date: Tue, 17 Apr 2007 13:19:54 -0700 (PDT)	[thread overview]
Message-ID: <657751.18080.qm@web36614.mail.mud.yahoo.com> (raw)
In-Reply-To: <20070417181016.GA10903@one.firstfloor.org>


--- Andi Kleen <andi@firstfloor.org> wrote:

> On Tue, Apr 17, 2007 at 01:47:39PM -0400, James Morris wrote:
> > Normal applications need zero modification under SELinux.
> > 
> > Some applications which manage security may need to be made SELinux-aware, 
> 
> Anything that can touch /etc/resolv.conf? That's potentially a lot of
> binaries
> if you consider anything scripts could do with it.

Well, no, you don't have to modify everything that might modify resolv.conf.
You do have to define your policy so that the set of things that might
modify resolv.conf is limited to the set of things that are appropriate.

You also need to note that SELinux has a notion of privilege that is
different from what is traditional. The ability to modify resolv.conf
is determined by the domain containing it and the relationship of the
domain containing the application to that domain, modified by any
domain transitions that may have occured to the process prior to or
during the attempted access.

> > although this can often be done with PAM plugins, which is a standard way 
> > to do this kind of thing in modern Unix & Linux OSs.
> 
> PAM plugins in vi and emacs? Scary idea.
> 
> And what do you do if someone decides to use OpenOffice to edit their
> /etc/resolv.conf? For a lot of people that's the only text editor 
> they know.

For SELinux to be effective it has to have a complete policy definition.
This would prevent the OpenOffice access (unless OpenOffice is in the
modify_resolv_conf_t domain) above.

This, by the way, is a fundimental advantage of a path scheme over a
label scheme in that label schemes require every object be labeled
(it's Section 3.1.1.3 of the TCSEC if you want to look it up) while a
path scheme (in the absences of a published requirement) only requires
those names it cares about. SELinux in the absence of a correct and
complete policy could be considered dangerous.


Casey Schaufler
casey@schaufler-ca.com

  reply	other threads:[~2007-04-17 20:26 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-16 21:33 AppArmor FAQ John Johansen
2007-04-17  0:20 ` James Morris
2007-04-17 15:03   ` David Safford
2007-04-17 16:00     ` Karl MacMillan
2007-04-17 18:05       ` Andi Kleen
2007-04-17 17:47         ` James Morris
2007-04-17 18:10           ` Andi Kleen
2007-04-17 20:19             ` Casey Schaufler [this message]
2007-04-17 20:50               ` James Morris
2007-04-17 21:16               ` Andi Kleen
2007-04-17 21:41                 ` Karl MacMillan
2007-04-17 21:51                   ` David Wagner
2007-04-17 22:17                     ` Alan Cox
2007-04-18  1:34                     ` James Morris
2007-04-18  1:55                       ` David Wagner
2007-04-18  2:20                         ` James Morris
2007-04-18  2:31                           ` David Wagner
2007-04-17 22:12                   ` Andi Kleen
2007-04-17 22:29                     ` Karl MacMillan
2007-04-17 21:58                 ` Alan Cox
2007-04-18 13:45                   ` James Morris
2007-04-18 14:33                     ` Shaya Potter
2007-04-18 19:41                     ` Crispin Cowan
2007-04-18 20:03                       ` Shaya Potter
2007-04-18 21:14                       ` James Morris
2007-04-19 16:35                         ` David Wagner
2007-04-19 17:39                           ` Stephen Smalley
2007-04-19 20:47                             ` David Wagner
2007-04-24  0:58                               ` Crispin Cowan
2007-04-24  2:03                                 ` Joshua Brindle
2007-04-25  1:03                                 ` Joshua Brindle
2007-04-19 17:14                       ` Stephen Smalley
2007-04-19 20:08                         ` David Wagner
2007-04-19 21:03                           ` Stephen Smalley
2007-04-19 21:08                             ` James Morris
2007-06-09 21:01                       ` Pavel Machek
2007-06-09 21:28                         ` david
2007-06-09 23:02                           ` Pavel Machek
2007-06-10  0:06                             ` david
2007-04-18 20:15                     ` David Lang
2007-04-19 17:27                       ` Stephen Smalley
2007-04-19 18:19                     ` Bernd Eckenfels
2007-04-19 20:19                       ` James Morris
2007-04-17 21:48               ` Karl MacMillan
2007-04-17 23:12                 ` Casey Schaufler
2007-04-17 22:26             ` Karl MacMillan
2007-04-19 17:46         ` Stephen Smalley
2007-04-20 18:45           ` David Lang
2007-04-20 19:23             ` Karl MacMillan
2007-04-17 23:09     ` Crispin Cowan
2007-04-17 23:20       ` Karl MacMillan
2007-04-17 23:53         ` David Wagner
2007-04-18  1:56           ` James Morris
2007-04-18  2:08             ` David Wagner
2007-06-09 19:38               ` Pavel Machek
2007-04-19 17:56       ` Stephen Smalley
2007-04-19 20:54         ` David Wagner
2007-04-19 21:17           ` Stephen Smalley
2007-04-17 21:55   ` Karl MacMillan
2007-04-17 22:55     ` Crispin Cowan
2007-04-17 23:13       ` Karl MacMillan
2007-06-09 14:11       ` Pavel Machek
2007-04-18  7:21     ` Rob Meijer
2007-04-18  7:08       ` David Lang
2007-04-18 13:33         ` James Morris
2007-04-18 12:15       ` Joshua Brindle
2007-04-18 13:31         ` Casey Schaufler
2007-04-18 14:05         ` Rob Meijer

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=657751.18080.qm@web36614.mail.mud.yahoo.com \
    --to=casey@schaufler-ca.com \
    --cc=andi@firstfloor.org \
    --cc=jmorris@namei.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /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