linux-kernel - Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

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]

Date:	Mon, 29 Oct 2007 12:41:46 -0700
From:	Crispin Cowan <crispin@...spincowan.com>
To:	rmeijer@...all.nl
CC:	casey@...aufler-ca.com, Chris Wright <chrisw@...s-sol.org>,
	Adrian Bunk <bunk@...nel.org>,
	Simon Arlott <simon@...e.lp0.eu>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Jan Engelhardt <jengelh@...putergmbh.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andreas Gruenbacher <agruen@...e.de>,
	Thomas Fricaccia <thomas_fricacci@...oo.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	James Morris <jmorris@...ei.org>,
	Giacomo Catenazzi <cate@...ian.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: Linux Security *Module* Framework (Was: LSM conversion to   
        static interface)

Rob Meijer wrote:
> On Mon, October 29, 2007 11:24, Crispin Cowan wrote:
>   
>>> Thus IMHO it may be a good idea to instead of a maintainer for LSM
>>> modules as proposed, alternatively a maintainer for each formal model
>>> may be more appropriate. This also would require module builders to
>>> first
>>> think about what formal model they are actualy using, thus resulting in
>>> cleaner module design.
>>>       
>> I *really* dislike this idea. It seems to set up the situation that the
>> only acceptable modules are those that follow some "formal" model.
>> Problems:
>> ...
>>     * The proposal only allows a single implementation of each formal
>>       model. In theory, theory is just like practice, but in practice it
>>       is not. SMACK and SELinux follow substantially similar formal
>>       models (not exactly the same) so should we exclude one and keep
>>       the other? No, of course not, because in practice they are very
>>       different.
>>     
> I would think the two may benefit from a role as described above.
> But I was thinking more in the line of new modules that may again
> implement this same model, and would thus benefit from interaction with
> this 'model maintainer' role.
>   
Ah! So the proposal really is to have an LSM maintainer for each
"family" of models, acting as a resource and arbiter for modules in a class.

I like that idea, and have no objection to it. However, it does have
resource problems, in that the pool of LSM maintainers is not that
large. There is also the likely objection that this degree of scale is
not needed until at least there are multiple families of models in the
upstream kernel, and possibly until there are multiple instances of a
single family in the upstream kernel.

It also begs the question of what constitutes a family.

    * AppArmor, SELinux, and TOMOYO are all ambient capability systems
          o AppArmor and TOMOYO are pathname based
          o SELinux is label based
    * SELinux and SMACK are label-based
          o I don't know if SMACK is an ambient capability system
    * Rob Meijer implicitly advocated for an object capability LSM
          o would it be pathname or label based? You could do either or
            both ...
    * The LSPP work from RH, Tresys, and TCS is MLS based
          o this is a subset of both label-based and ambient capability
            based
    * I have no clue what family to put MultiADM or Dazuko into
    * Getting very formal, I could imagine a Clarke-Wilson module
    * Getting very informal, I could imagine a module that is a
      collection of cute intrusion prevention hacks, such as the Open
      wall Linux symlink and hardlink restrictions, and my own RaceGuard
      work
          o Oh wait, I published
            <http://citeseer.ist.psu.edu/cowan01raceguard.html>
            RaceGuard. Does that make it formal? :-)

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/