Re: AppArmor Security Goal

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

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.

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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: AppArmor Security Goal
    ... has their own workstation, and thus has root on that workstation. ... edit security policy is probably a good idea. ... why does it matter if there is one non-priveliged user or many? ...
    (Linux-Kernel)
  • Re: IP access
    ... > Hello list members! ... > workstation and the IP address are equal to the predefined values. ... > the account of an other workstation by changing the IP address. ... Only root can change the IP address of a linux host. ...
    (Fedora)
  • Re: Office 2000 on SBS2003?
    ... I'm a woman Root. ... we're going to agree to disagree, than we're agreeing to disagree no ... ;-) But honestly, it's your server Root. ... >>you'd be reading this email from a workstation. ...
    (microsoft.public.windows.server.sbs)
  • Re: booting from the network
    ... then (as root): ... You'll need to be running dhcpd, tftp, and nfs - the ltspcfg utility ... for the workstation to boot from - that can be generated at ...
    (Fedora)