On Tue, Jul 28, 2015 at 10:13 AM, David Drysdale <drysdale@xxxxxxxxxx> wrote: > On Tue, Jul 28, 2015 at 5:43 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> On Tue, Jul 28, 2015 at 4:41 AM, David Drysdale <drysdale@xxxxxxxxxx> wrote: >>> Add a document describing the process of adding a new system call, >>> including the need for a flags argument for future compatibility, and >>> covering 32-bit/64-bit concerns (albeit in an x86-centric way). >>> >>> Signed-off-by: David Drysdale <drysdale@xxxxxxxxxx> >>> Reviewed-by: Michael Kerrisk <mtk.manpages@xxxxxxxxx> >> >> This is great! >> >> Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> >> >> I have a few minor suggestions below... > > Thanks, I've applied all bar one -- a query below. > >>> --- >>> Documentation/adding-syscalls.txt | 454 ++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 454 insertions(+) >>> create mode 100644 Documentation/adding-syscalls.txt >>> >>> diff --git a/Documentation/adding-syscalls.txt b/Documentation/adding-syscalls.txt >>> new file mode 100644 >>> index 000000000000..5f52edda8951 >>> --- /dev/null >>> +++ b/Documentation/adding-syscalls.txt > > [snip] > >>> + - If there is an existing capability that governs related functionality, then >>> + use that. However, avoid combining lots of only vaguely related functions >>> + together under the same bit, as this goes against capabilities' purpose of >>> + splitting the power of root. In particular, avoid adding new uses of the >>> + already overly-general CAP_SYS_ADMIN capability. >>> + - If there is no related capability, then consider adding a new capability >>> + bit -- but bear in mind that the numbering space is limited, and each new >>> + bit needs to be understood and administered by sysadmins. >> >> Perhaps mention alternative mechanisms for access control when working >> on file descriptors, like avoiding security issues by looking at fd >> _opener_ credentials, rather than current's credentials? > > I'm struggling to cope up with text about this that doesn't feel either > too vague or much too detailed / internal, so maybe I'm misunderstanding > what you're after. Could you clarify or maybe suggest a sentence or two? Hm, yes, I think you're right: my suggestion here was too specific. Please ignore! :) -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
