linux-kernel - Re: AppArmor Security Goal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47363381.4030103@crispincowan.com>
Date:	Sat, 10 Nov 2007 14:41:05 -0800
From:	Crispin Cowan <crispin@...spincowan.com>
To:	"Dr. David Alan Gilbert" <linux@...blig.org>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	LSM ML <linux-security-module@...r.kernel.org>,
	apparmor-dev <apparmor-dev@...ge.novell.com>
Subject: Re: AppArmor Security Goal

Dr. David Alan Gilbert wrote:
> * Crispin Cowan (crispin@...spincowan.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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/