On Tue, Jul 28, 2015 at 10:13 AM, David Drysdale <drysd...@google.com> wrote: > On Tue, Jul 28, 2015 at 5:43 PM, Kees Cook <keesc...@chromium.org> wrote: >> On Tue, Jul 28, 2015 at 4:41 AM, David Drysdale <drysd...@google.com> 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 <drysd...@google.com> >>> Reviewed-by: Michael Kerrisk <mtk.manpa...@gmail.com> >> >> This is great! >> >> Reviewed-by: Kees Cook <keesc...@chromium.org> >> >> 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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
