From: Roland McGrath <roland@hack.frob.com>
To: Kees Cook <keescook@chromium.org>
Cc: oleg@redhat.com, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
James Morris <jmorris@namei.org>
Subject: Re: [PATCH v6 0/3] security: Yama LSM
Date: Fri, 18 Nov 2011 13:45:27 -0800 (PST) [thread overview]
Message-ID: <20111118214527.CE6AC2C0E7@topped-with-meat.com> (raw)
In-Reply-To: Kees Cook's message of Friday, 18 November 2011 13:39:38 -0800 <CAGXu5jJ4h+uCF50DqbLe1m6CRr_Mw3pWq4mEm8nRtDPKV9C2Rg@mail.gmail.com>
> 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
next prev parent reply other threads:[~2011-11-18 21:45 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-26 23:49 Kees Cook
2011-10-26 23:49 ` [PATCH 1/3] " Kees Cook
2011-10-26 23:49 ` [PATCH 2/3] security: create task_free security callback Kees Cook
2011-10-26 23:49 ` [PATCH 3/3] security: Yama: add ptrace relationship tracking interface Kees Cook
2011-11-19 16:30 ` Vasiliy Kulikov
2011-11-19 16:59 ` Solar Designer
2011-11-21 18:40 ` Kees Cook
2011-11-01 20:45 ` [PATCH v6 0/3] security: Yama LSM James Morris
2011-11-01 21:05 ` Kees Cook
2011-11-01 21:37 ` James Morris
2011-11-01 23:23 ` Kees Cook
2011-11-18 4:17 ` James Morris
2011-11-18 21:39 ` Kees Cook
2011-11-18 21:45 ` Roland McGrath [this message]
2011-11-18 22:44 ` Kees Cook
2011-11-18 23:18 ` Kees Cook
2011-11-21 19:18 ` [RFC] Make Yama pid_ns aware Vasiliy Kulikov
2011-11-21 19:42 ` Kees Cook
2011-11-22 18:13 ` Serge Hallyn
2011-11-22 19:20 ` Vasiliy Kulikov
2011-11-22 20:10 ` Serge Hallyn
2011-11-23 7:45 ` Vasiliy Kulikov
2011-11-23 14:41 ` Serge Hallyn
2011-11-23 14:49 ` Serge E. Hallyn
2011-11-23 16:55 ` Vasiliy Kulikov
2011-11-23 17:00 ` Serge Hallyn
2011-11-28 18:12 ` Kees Cook
2011-11-28 18:14 ` Vasiliy Kulikov
2011-11-28 19:16 ` [RFC -resend] " Vasiliy Kulikov
2011-11-28 19:35 ` Kees Cook
2011-11-28 20:15 ` Kees Cook
2011-11-28 20:00 ` Serge E. Hallyn
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=20111118214527.CE6AC2C0E7@topped-with-meat.com \
--to=roland@hack.frob.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=oleg@redhat.com \
/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
all inboxes | Powered by JetHome®