linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: "Serge E. Hallyn" <serge@hallyn.com>,
	Casey Schaufler <casey@schaufler-ca.com>,
	James Morris <jmorris@namei.org>,
	Kees Cook <keescook@chromium.org>,
	Andy Lutomirski <luto@amacapital.net>,
	John Stultz <john.stultz@linaro.org>, Jann Horn <jann@thejh.net>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Cc: mtk.manpages@gmail.com, linux-man <linux-man@vger.kernel.org>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: RFC: capabilities(7): notes for kernel developers
Date: Thu, 15 Dec 2016 12:40:56 +0100	[thread overview]
Message-ID: <cdbc35f2-925e-aa65-98e7-a4ae4a5ded2c@gmail.com> (raw)

Hello all,

Because the topic every now then comes up "which capability 
should I associate with the new feature that I'm adding to 
the kernel?", I propose to add the text below to the 
capabilities(7) man page [1] with some recommendations
on how to go about choosing. I would be happy
to get feedback, suggestions for improvement and
so on.

Cheers,

Michael

[1] http://man7.org/linux/man-pages/man7/capabilities.7.html


   Notes to kernel developers
       When adding a new kernel feature that  should  be  governed  by  a
       capability, consider the following points.

       *  The  goal of capabilities is divide the power of superuser into
          small pieces, such that if a program that has  capabilities  is
          compromised, its power to do damage to the system would be much
          less than a similar set-user-ID-root program.

       *  You have the choice of either creating  a  new  capability  for
          your  new  feature,  or associating the feature with one of the
          existing capabilities.  Because the size of capability sets  is
          currently  limited to 64 bits, the latter option is preferable,
          unless there are compelling reasons to take the former option.

       *  To determine which existing capability might best be associated
          with your new feature, review the list of capabilities above in
          order to find a "silo" into which your new feature best fits.

       *  Don't choose CAP_SYS_ADMIN if you can  possibly  avoid  it!   A
          vast  proportion  of  existing capability checks are associated
          with this capability, to the point where it  can  plausibly  be
          called "the new root".  Don't make the problem worse.  The only
          new features that should be associated with  CAP_SYS_ADMIN  are
          ones that closely match existing uses in that silo.

       *  If  you have determined that it really is necessary to create a
          new capability for your feature, avoid making (and  naming)  it
          as  a "single-use" capability.  Thus, for example, the addition
          of the highly specific CAP_WAKE_ALARM was probably  a  mistake.
          Instead,  try  to  identify  and  name your new capability as a
          broader silo into which other related future  use  cases  might
          fit.


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

             reply	other threads:[~2016-12-15 11:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-15 11:40 Michael Kerrisk (man-pages) [this message]
2016-12-15 16:29 ` RFC: capabilities(7): notes for kernel developers Casey Schaufler
2016-12-15 19:41   ` Michael Kerrisk (man-pages)
2016-12-15 20:40     ` Casey Schaufler
2016-12-16  0:31       ` John Stultz
2016-12-16  0:44         ` Casey Schaufler
2016-12-16 14:55           ` Michael Kerrisk (man-pages)
2016-12-16 20:10             ` Serge E. Hallyn
2016-12-16 20:20               ` John Stultz
2016-12-16 21:05                 ` Serge E. Hallyn
2016-12-16 21:16                   ` John Stultz
2016-12-19 20:20                     ` Rafael J. Wysocki
2016-12-17 21:01               ` Michael Kerrisk (man-pages)
2016-12-16 15:04       ` Michael Kerrisk (man-pages)

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=cdbc35f2-925e-aa65-98e7-a4ae4a5ded2c@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=casey@schaufler-ca.com \
    --cc=ebiederm@xmission.com \
    --cc=jann@thejh.net \
    --cc=jmorris@namei.org \
    --cc=john.stultz@linaro.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=serge@hallyn.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;
as well as URLs for NNTP newsgroup(s).