linux-kernel - Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

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]

Date:	Sun, 17 Jun 2007 18:51:29 -0700 (PDT)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	James Morris <jmorris@...ei.org>,
	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Greg KH <greg@...ah.com>, Pavel Machek <pavel@....cz>,
	Crispin Cowan <crispin@...ell.com>,
	Andreas Gruenbacher <agruen@...e.de>,
	Stephen Smalley <sds@...ho.nsa.gov>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

--- James Morris <jmorris@...ei.org> wrote:

> On Fri, 15 Jun 2007, Casey Schaufler wrote:
> 
> > 
> > --- James Morris <jmorris@...ei.org> wrote:
> > 
> > > On my system, it takes about 1.2 seconds to label a fully checked out 
> > > kernel source tree with ~23,000 files in this manner
> > 
> > That's an eternity for that many files to be improperly labeled.
> > If, and the "if" didn't originate with me, your policy is
> > demonstrably correct (how do you do that?) for all domains
> > you could claim that the action is safe, if not ideal. 
> > I can't say if an evaluation team would buy the "safe"
> > argument. They've been known to balk before.
> 
> To clarify:
> 
> We are discussing a scheme where the underlying SELinux labeling policy 
> always ensures a safe label on a file, and then relabeling newly created 
> files according to their pathnames.

To counter clarify:

You are saying two things:
1. The policy always ensures a safe label.
2. Files can be relabeled in a reasonable and timely manner.

I have no questions about 2. It's a hack, but you've already
acknowledged that and it will work, allowing for some potential
cases where someone is overeager about getting a file-in-transition.

Regarding 1: This is a founding premise of the arguement, that
the "policy" is written correctly such that there is no case
where a file gets created with an unsafe label. Given the external
nature of the policy, and the number of attributes used within
the policy, and the overall sophistication of the policy mechanism,
how does one ...

    a. know that a label is "safe"
    b. know that a file will get a "safe" label
    c. know that the policy is "correctly" written as required

The question is not if fixxerupperd can set things right.
The question is about the properly written policy that is
required to make the mechanism worth discussing.

> There is no expectation that this scheme would be submitted for 
> certification.

De-nial.

> Its purpose is to merely to provide pathname-based 
> labeling outside of the kernel.

If you already have an in-kernel labeling scheme that you
trust to make the world safe until you get around to doing
the labeling externally you can argue that it's good enough.
But, to quote Cinderella's Stepmother, "I said "if"".

Casey Schaufler
casey@...aufler-ca.com
-
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/