From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936553AbcLOQ3z (ORCPT ); Thu, 15 Dec 2016 11:29:55 -0500 Received: from nm3-vm6.bullet.mail.ne1.yahoo.com ([98.138.91.96]:34258 "EHLO nm3-vm6.bullet.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936476AbcLOQ3x (ORCPT ); Thu, 15 Dec 2016 11:29:53 -0500 X-Yahoo-Newman-Id: 37099.81680.bm@omp1019.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 2h6pEpcVM1kgzUSWETrGvDnn2WkGgrXJkw3Gqzn_BrutncE q3Rz6pwv8OIxVjpqOnECXjEJIHlq8BjOAkfNtx__2A33Ht5I5WIm.ipmZeWE mAuXg89zLzoewkqaqUHuHKuEmEwaBrOvsXX2_RHdXAsJKfU7sh.hR02R5gTI UbBa0EpB6fMl7Lscb8S9_4Sm.0E3MT1.YrcacEqQa.tHAFGJUXpyofagmhnB XaU0x4hPjnESdw.sSuwW40yCfOimU79M8st0hoofOrn2b5gDF640Hnjjlrbr SuHUIUfh8qwjOkfwi1xV_xCQdDr2KGW.wG35DocgGotazUW_EQESPYL_t4aQ IgDhLFKNdCKcvioknDBc.iMJm2Ez6443LUM0SA7weZi2F12dDbmobwoaqBzG _hsafprA9ZX69zOLi.GDZjFKqcNnOIrvWgwimJqHHkWCdNxVauDTkn8Kfuir JxleAR7Nzrx7hUaGiueibaR5drzDIGxzIHZmehe1BFp4iSY82gHVDFimjfGv Pwoz.4hFpj_zLhxhzoplR._jYX7LSw9tuDhoQ8qsLuBhpLsAusQJOfd5rM8C 7EcTq9vMaE5XiNfNoEkFq7Xji2gAUz9jbKwuFChi46hXx2OCm X-Yahoo-SMTP: OIJXglSswBDfgLtXluJ6wiAYv6_cnw-- Subject: Re: RFC: capabilities(7): notes for kernel developers To: "Michael Kerrisk \(man-pages\)" , "Serge E. Hallyn" , James Morris , Kees Cook , Andy Lutomirski , John Stultz , Jann Horn , "Eric W. Biederman" References: Cc: linux-man , linux-security-module , lkml From: Casey Schaufler Message-ID: Date: Thu, 15 Dec 2016 08:29:48 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/15/2016 3:40 AM, Michael Kerrisk (man-pages) wrote: > 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. Thank you. This is long overdue. > 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 I wouldn't say "small". Small implies many, and we want to keep the number of capabilities manageable. > compromised, its power to do damage to the system would be much > less than a similar set-user-ID-root program. Not "much less", just less. Change "similar set-user-ID-root program" to "the same program running with root privilege". > * 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, The reason is not the size of the set being limited, it is that a large set of capabilities would be unmanageable. The fact that someone is reading this is sufficient evidence of that. > 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. One approach to take is to determine if there are other features requiring capabilities that will always be use along with the new feature. If the new feature is useless without these other features, you should use the same capability as the other features. > * 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. I don't agree with this advice. Use CAP_SYS_ADMIN if you are preforming system administration functions. Odds are very good that if a program is using one system administration feature it will be using others. > * 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. Be strong. Don't say "avoid making (and naming)", say "don't make or name". We can't allow single use capabilities. If we did that we'd have thousands of capabilities. It's hard enough to get developers to use a coarse set of capabilities. > 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. Need a better example. CAP_WAKE_ALARM could readily be CAP_TIME.