linux-kernel - Re: [PATCH v6 0/3] security: Yama LSM

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]

Message-Id: <20111118214527.CE6AC2C0E7@topped-with-meat.com>
Date:	Fri, 18 Nov 2011 13:45:27 -0800 (PST)
From:	Roland McGrath <roland@...k.frob.com>
To:	Kees Cook <keescook@...omium.org>
Cc:	oleg@...hat.com, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	James Morris <jmorris@...ei.org>
Subject: Re: [PATCH v6 0/3] security: Yama LSM

> Do you have any objection to my LSM performing ptrace restrictions?
> It's entirely self-contained, and all the major upstream crash
> handlers are already using the prctl() interface it uses to declare
> ptrace attach relationships.

I don't have the context of what your LSM does.  But other LSMs apply their
own rules in security_ptrace().  That's what the hook is for.  I'm not sure
why we would object from the perspective of core ptrace functionality.
LSMs are LSMs.  Their behavior is between you and your users, as far as I
am concerned.  As experts on ptrace and aficionados of its users, we may
have thoughts on what constraints on ptrace users would find annoying.
But that doesn't mean we'd object per se to whatever bizarre constraints
users want to ask an LSM to put on them.

Thanks,
Roland
--
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/