public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Amon Ott <ao@rsbac.org>
To: rsbac@rsbac.org
Cc: "Casey Schaufler" <casey@schaufler-ca.com>,
	"Lorenzo HernándezGarcía-Hierro" <lorenzo@gnu.org>,
	"linux-security-module@wirex.com"
	<linux-security-module@wirex.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [rsbac] Thoughts on the "No Linux Security Modules framework" old claims
Date: Tue, 22 Feb 2005 09:57:10 +0100	[thread overview]
Message-ID: <200502220957.16047.ao@rsbac.org> (raw)
In-Reply-To: <20050221175026.22737.qmail@web50205.mail.yahoo.com>

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

On Montag 21 Februar 2005 18:50, Casey Schaufler wrote:
> 
> --- Lorenzo Hernández García-Hierro <lorenzo@gnu.org>
> wrote:
> 
> 
> > > There are cases where Linux DAC and MAC cannot
> > live happily together, 
> > > because Linux DAC is too limited.
> > 
> > Agreed.
> 
> OKay, I'll bite. MAC and DAC are seperate.
> How is it that (the limited nature of) the DAC
> behavior makes a system with both unhappy?

Back in 2001/2002 (versions 1.1.2 and 1.2.0), I added DAC disabling 
support first for the full filesystem, then for selected dir trees 
and the converter tool linux2acl to RSBAC. I remember the actual 
problem coming from a provider of virtual web servers, but I cannot 
find the old mails. Too long ago.

We were not able to solve the given problem without changing the Linux 
mode to 0777 (what means disabling DAC effectively). The reason to 
add this feature was that the dir mode should not be changed to 0777, 
because this would leave it completely unprotected with a non-RSBAC 
kernel. Some programs even check Linux modes and refuse to run with 
too many rights on their config files (what is usually a good idea, 
but sometimes problematic), this is also a convenient workaround for 
those.

Personally, I do not use the object based override myself, but rather 
subject based override with additional Linux capabilities for 
selected accounts and/or programs (which can be set with the RSBAC 
CAP module, and which are dangerous because of LD_PRELOAD etc., if 
the environment is not controlled). This means that I have to use MAC 
configuration to restrict these users/programs afterwards, but that 
is not the problem.

The moment you want to implement separation of duty for 
administration, you will again and again run against Linux DAC 
limits, because it only knows of one single admin. E.g. think of a 
separate account doing user management and adding user dirs.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

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

  reply	other threads:[~2005-02-22  8:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-15 22:38 Thoughts on the "No Linux Security Modules framework" old claims Lorenzo Hernández García-Hierro
2005-02-16  4:21 ` Valdis.Kletnieks
2005-02-16 13:29   ` Lorenzo Hernández García-Hierro
2005-02-16 13:30     ` Stephen Smalley
2005-02-16 16:07     ` Casey Schaufler
2005-02-16 15:52   ` Casey Schaufler
2005-02-16 17:41     ` Valdis.Kletnieks
2005-02-21 10:19 ` [rsbac] " Amon Ott
2005-02-21 17:15   ` Lorenzo Hernández García-Hierro
2005-02-21 17:50     ` Casey Schaufler
2005-02-22  8:57       ` Amon Ott [this message]
2005-02-22 15:23         ` Casey Schaufler
2005-02-24  0:55   ` Kurt Garloff
2005-02-24  8:28     ` Amon Ott
2005-02-25 10:14       ` Kurt Garloff
2005-02-23 21:37 ` Crispin Cowan
2005-02-23 22:00   ` Lorenzo Hernández García-Hierro
2005-02-23 22:07     ` Crispin Cowan
2005-02-23 22:34       ` Lorenzo Hernández García-Hierro
2005-02-24 13:23   ` Stephen Smalley

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=200502220957.16047.ao@rsbac.org \
    --to=ao@rsbac.org \
    --cc=casey@schaufler-ca.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@wirex.com \
    --cc=lorenzo@gnu.org \
    --cc=rsbac@rsbac.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