All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Johansen <jjohansen@suse.de>
To: Crispin Cowan <crispin@crispincowan.com>
Cc: "Dr. David Alan Gilbert" <linux@treblig.org>,
	Arjan van de Ven <arjan@infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	LSM ML <linux-security-module@vger.kernel.org>,
	apparmor-dev <apparmor-dev@forge.novell.com>
Subject: Re: AppArmor Security Goal
Date: Mon, 12 Nov 2007 17:20:14 -0800	[thread overview]
Message-ID: <20071113012014.GA16006@suse.de> (raw)
In-Reply-To: <4738E6E3.5090404@crispincowan.com>

[-- Attachment #1: Type: text/plain, Size: 2853 bytes --]

On Mon, Nov 12, 2007 at 03:50:59PM -0800, Crispin Cowan wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan (crispin@crispincowan.com) wrote:
> >   
> >> I mostly don't see this as a serious limitation, because almost everyone
> >> has their own workstation, and thus has root on that workstation. There
> >> are 2 major exceptions:
> >>
> >>     * Schools, where the "workstations" are thin client X terminals and
> >>       everyone is logged into a giant shared machine. Sorry, AppArmor is
> >>       not a good choice for that environment, but it is a pretty scarce
> >>       environment.
> >>     * Enterprises, where workers get their own workstation, but they
> >>       don't get root. Well, the reason the worker doesn't get root is
> >>       the enterprise doesn't trust them with it, and so not letting them
> >>       edit security policy is probably a good idea.
> >>     
> > I don't actually see your distinction here between those two environments;
> > why does it matter if there is one non-priveliged user or many?
> >   
> Because it is easier to solve if there is only one non-privileged user:
> you just give them privilege (fun with chmod and sudo) to edit the
> system policies, and you're done (assuming you are happy allowing the
> non-privileged user to edit policy at all).
> 
> If there are lots of non-privileged users sharing a computer, then I
> submit that solutions are either insecure, intractable, or purely
> restrictive.
> 
yep, it needs to be purely restrictive

> >> Can you explain why you want a non-privileged user to be able to edit
> >> policy? I would like to better understand the problem here.
> >>     
> > I think it might depend on how strict the users starting point is;
> > you could say:
> >    1 This document editor can read and write any part of the users home
> >      directory other than the . files.
> >
> > or you could say:
> >    2 This document editor can read any files but only write to the
> >      'Documents directory'.
> >
> > If the adminisrator set something up with (2) as the starting point it
> > would seem reasonable for the user to be able to add the ability to edit
> > documents in extra directories for their style of organising documents
> > they work on; but they would be restricted in what they could add
> > so that they couldn't add the ability to write to their settings
> > files.
> >   
> Ok, I can see where that would be useful in theory. But solving it is
> VERY hard in practice, and AppArmor is not attempting to address this
> problem of user extensibility of mandatory access controls.
> 
Well at least its not on Crispin's list.  It is something I have been
interested in for a long time.  I can't say when or it will happen
as I need to find some, ever elusive, spare time to work on it.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

  reply	other threads:[~2007-11-13  1:20 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-08 21:33 AppArmor Security Goal Crispin Cowan
2007-11-10 21:04 ` Andi Kleen
2007-11-10 21:24   ` Crispin Cowan
2007-11-11  3:23     ` John Johansen
2007-11-10 21:28   ` david
2007-11-11  3:36     ` John Johansen
2007-11-10 22:04 ` Dr. David Alan Gilbert
2007-11-10 22:11   ` Crispin Cowan
2007-11-10 22:24     ` Dr. David Alan Gilbert
2007-11-10 22:41       ` Crispin Cowan
2007-11-10 22:57         ` Alan Cox
2007-11-10 23:14           ` Crispin Cowan
2007-11-10 23:54             ` Alan Cox
2007-11-10 23:25         ` Dr. David Alan Gilbert
2007-11-10 23:52           ` david
2007-11-10 23:47             ` Dr. David Alan Gilbert
2007-11-10 23:56             ` Alan Cox
2007-11-11  1:27               ` david
2007-11-11  3:59                 ` John Johansen
2007-11-12 23:58               ` Crispin Cowan
2007-11-11  4:17             ` John Johansen
2007-11-11  4:50               ` david
2007-11-13  0:13             ` Crispin Cowan
2007-11-11  7:02           ` Rogelio M. Serrano Jr.
2007-11-12 23:50           ` Crispin Cowan
2007-11-13  1:20             ` John Johansen [this message]
2007-11-11  2:17         ` Casey Schaufler
2007-11-11  3:55           ` John Johansen
2007-11-13  0:10           ` Joshua Brindle
2007-11-13  4:58             ` Casey Schaufler
  -- strict thread matches above, loose matches on Subject: below --
2007-11-11  8:16 Rob Meijer
     [not found] <9nngC-6iQ-25@gated-at.bofh.it>
     [not found] ` <9o6Qq-2Hk-17@gated-at.bofh.it>
     [not found]   ` <9o6Qq-2Hk-15@gated-at.bofh.it>
     [not found]     ` <9o706-2Xe-17@gated-at.bofh.it>
     [not found]       ` <9o7jp-3lE-5@gated-at.bofh.it>
     [not found]         ` <9o7Wg-4sT-15@gated-at.bofh.it>
     [not found]           ` <9of7j-7ej-7@gated-at.bofh.it>
2007-11-12 18:43             ` Bodo Eggert

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=20071113012014.GA16006@suse.de \
    --to=jjohansen@suse.de \
    --cc=apparmor-dev@forge.novell.com \
    --cc=arjan@infradead.org \
    --cc=crispin@crispincowan.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux@treblig.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 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.