linux-kernel - Re: [PATCH v12 0/9] LSM: Multiple concurrent LSMs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20130108063445.GA4537@cachalot>
Date:	Tue, 8 Jan 2013 10:34:45 +0400
From:	Vasily Kulikov <segoon@...nwall.com>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	James Morris <jmorris@...ei.org>,
	LSM <linux-security-module@...r.kernel.org>,
	LKLM <linux-kernel@...r.kernel.org>,
	SE Linux <selinux@...ho.nsa.gov>,
	John Johansen <john.johansen@...onical.com>,
	Eric Paris <eparis@...hat.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Kees Cook <keescook@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v12 0/9] LSM: Multiple concurrent LSMs

On Mon, Jan 07, 2013 at 20:11 -0800, Casey Schaufler wrote:
> On 1/7/2013 7:59 PM, Stephen Rothwell wrote:
> > You probably also want to think a bit harder about the order of the
> > patches - you should introduce new APIs before you use them and remove
> > calls to functions before you remove the functions.
> >
> The unfortunate reality is that I couldn't find a good way to stage the
> changes. It's a wonking big set of infrastructure change. I could introduce
> the security blob abstraction separately but that is a fraction of the
> change. If it would have gone through mail filters as a single patch I'd
> have sent it that way.
> 
> I can spend time on patch presentation, and will if necessary.

I guess it can be divided this way:

1) Introduce lsm_get_cred(), etc. which unconditionally return
->security, ->i_security, etc.

2) Move all LSMs, procfs, etc. to the new API, a patch per LSM/subsystem.

3) Change structures along with new API.


The pro of the division is that if you have a bug in the series (and you
surely have! ;)) it is MUCH more simple to locate this bug (bisect, etc.).
Also it is more descriptive as you divide LSM changes and the core security
subsystem itself targeted on multiple LSMs which divides LSM
implementations (which might be not very important for someone) and the core
architecture (which is important for everybody).

Thanks,

-- 
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
--
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/