public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Crispin Cowan <crispin@crispincowan.com>
To: "Dr. David Alan Gilbert" <linux@treblig.org>
Cc: 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: Sat, 10 Nov 2007 14:41:05 -0800	[thread overview]
Message-ID: <47363381.4030103@crispincowan.com> (raw)
In-Reply-To: <20071110222414.GC24195@gallifrey>

Dr. David Alan Gilbert wrote:
> * Crispin Cowan (crispin@crispincowan.com) wrote:
>   
>> I don't get the problem: if you want your web browser to be able to
>> access where you commonly store your documents, then give it that
>> permission. The above rule says that your web browser doesn't get to go
>> change AppArmor policy on its own.
>>     
> But can I as a non-privileged user say which directories I want it to
> be able to access?
>   
No, you have to be privileged (root) to edit security policy and to
reload policy.

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.

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.

Note that John Johansen is also interested in allowing non-privileged
users to manipulate AppArmor policy, but his view was to only allow a
non-privileged user to further tighten the profile on a program. To me,
that adds complexity with not much value, but if lots of users want it,
then I'm wrong :)

>> I have serious doubts about the utility of restricting a text editor.
>> You nominally want to be able to edit any file on the system, so
>> confining it would be fairly meaningless.
>>     
> Text editor probably true; but I'm thinking here more of OpenOffice
> and the like; there have been plenty of document carried malware in the
> past.
>   
How to usefully confine an office suite like OpenOffice is current work
at Mercenary Linux. We think we have a solution that is just AppArmor
policy, without having to do any feature enhancements.

>>> Similarly I'd like to be able to split applications so that
>>> the 'preferences' editing facilities are done by separate
>>> envrionments so that there is no way that a fault in parsing
>>> external data could edit the config (e.g. change home page or
>>> proxy in a browser or default document in an editor).  
>>>       
>> AppArmor will let you do that; most of the work is in splitting the
>> application. If you can get e.g. Firefox to use a separate process that
>> it exec's for editing your preferences, then AppArmor can confine that
>> helper app with a different policy than Firefox itself, including
>> granting the helper write permission to the config directory.
>>     
> Yes, and designing the app so that it's filenames are predictable;
> firefox has a fun habit of using randomly named profile directories.
>   
You just glob that directory, so the rule would look like:

/home/*/.mozilla/default/*/prefs.js rw,

if you wanted it to be a generic policy for all users. If you want a
tighter policy for your workstation, then it might look like

/home/dagilbert/.mozilla/default/somemozillarandomstring/prefs.js rw,

hard-coding both your username and the random directory name that
Mozilla chose.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux		   http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work


  reply	other threads:[~2007-11-10 22:40 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 [this message]
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
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=47363381.4030103@crispincowan.com \
    --to=crispin@crispincowan.com \
    --cc=apparmor-dev@forge.novell.com \
    --cc=arjan@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox