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/
WARNING: multiple messages have this Message-ID (diff)
From: "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>, Casey Schaufler <casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>, James Morris <jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>, Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>, Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>, John Stultz <john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Jann Horn <jann-XZ1E9jl8jIdeoWH0uzbU5w@public.gmane.org>, "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, linux-security-module <linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.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/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2016-12-15 11:41 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-12-15 11:40 Michael Kerrisk (man-pages) [this message] 2016-12-15 11:40 ` RFC: capabilities(7): notes for kernel developers Michael Kerrisk (man-pages) 2016-12-15 16:29 ` Casey Schaufler 2016-12-15 16:29 ` Casey Schaufler 2016-12-15 19:41 ` Michael Kerrisk (man-pages) 2016-12-15 20:40 ` Casey Schaufler 2016-12-15 20:40 ` Casey Schaufler 2016-12-16 0:31 ` John Stultz 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 14:55 ` Michael Kerrisk (man-pages) 2016-12-16 20:10 ` Serge E. Hallyn 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-16 21:16 ` John Stultz 2016-12-19 20:20 ` Rafael J. Wysocki 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) 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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.