From: David Drysdale <drysdale@google.com> To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Kees Cook <keescook@chromium.org>, "Eric W. Biederman" <ebiederm@xmission.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Meredydd Luff <meredydd@senatehouse.org>, Will Drewry <wad@chromium.org>, Jorge Lucangeli Obes <jorgelo@google.com>, Ricky Zhou <rickyz@google.com>, Lee Campbell <leecam@google.com>, Julien Tinnes <jln@google.com>, Mike Depinet <mdepinet@google.com>, James Morris <james.l.morris@oracle.com>, Andy Lutomirski <luto@amacapital.net>, Paolo Bonzini <pbonzini@redhat.com>, Paul Moore <paul@paul-moore.com>, Christoph Hellwig <hch@infradead.org>, Linux API <linux-api@vger.kernel.org>, LSM List <linux-security-module@vger.kernel.org>, fstests@vger.kernel.org Subject: Re: [PATCHv3 man-pages 3/3] open.2: describe O_BENEATH flag Date: Mon, 9 Mar 2015 15:16:34 +0000 [thread overview] Message-ID: <CAHse=S_kMkiV8hB5Y1=kVGCi3ZusRm5G=EyXhY_+PRycSt7GSw@mail.gmail.com> (raw) In-Reply-To: <54FDAF16.2030407@gmail.com> On Mon, Mar 9, 2015 at 2:32 PM, Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote: > On 03/09/2015 03:00 PM, David Drysdale wrote: >> Signed-off-by: David Drysdale <drysdale@google.com> > > Hi David, > > The text looks good insofar as it goes. But, it would be helpful > to have sentence or to that explains why this flag exists. > Could you add that, please? > > Thanks, > > Michael How about something like: This feature allows applications to be sure that the opened file is within the specified directory, regardless of the original source of the pathname argument. Some security-conscious pro‐ grams may further ensure this by imposing a system call filter (with seccomp(2)) that requires this flag for all open() opera‐ tions, so that the program cannot open files outside of speci‐ fied directories even if subverted. (Also, I realize that I somehow failed to notice that the flags are listed in alphabetical order, so I'll move the text up, as in the updated diff below). Thanks, David --- man2/open.2 | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/man2/open.2 b/man2/open.2 index 956531b24b26..ece1fa90775a 100644 --- a/man2/open.2 +++ b/man2/open.2 @@ -201,6 +201,43 @@ See for further details. See also BUGS, below. .TP +.B O_BENEATH " (since Linux 4.??)" +Ensure that the +.I pathname +is beneath the current working directory (for +.BR open (2)) +or the +.I dirfd +(for +.BR openat (2)). +If the +.I pathname +is absolute or contains a path component of "..", the +.BR open () +fails with the error +.BR EPERM. +This occurs even if ".." path component would not actually +escape the original directory; for example, a +.I pathname +of "subdir/../filename" would be rejected. +Path components that are symbolic links to absolute paths, or that are +relative paths containing a ".." component, will also cause the +.BR open () +operation to fail with the error +.BR EPERM. + +This feature allows applications to be sure that the opened file is +within the specified directory, regardless of the original source of the +.I pathname +argument. +Some security-conscious programs may further ensure +this by imposing a system call filter (with +.BR seccomp (2)) +that requires this flag for all +.BR open () +operations, so that the program cannot open files outside of +specified directories even if subverted. +.TP .BR O_CLOEXEC " (since Linux 2.6.23)" .\" NOTE! several other man pages refer to this text Enable the close-on-exec flag for the new file descriptor. @@ -984,6 +1021,13 @@ did not match the owner of the file and the caller was not privileged The operation was prevented by a file seal; see .BR fcntl (2). .TP +.B EPERM +The +.B O_BENEATH +flag was specified and the +.I pathname +was not beneath the relevant directory. +.TP .B EROFS .I pathname refers to a file on a read-only filesystem and write access was -- 2.2.0.rc0.207.ga3a616c
WARNING: multiple messages have this Message-ID (diff)
From: David Drysdale <drysdale@google.com> To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Kees Cook <keescook@chromium.org>, "Eric W. Biederman" <ebiederm@xmission.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Meredydd Luff <meredydd@senatehouse.org>, Will Drewry <wad@chromium.org>, Jorge Lucangeli Obes <jorgelo@google.com>, Ricky Zhou <rickyz@google.com>, Lee Campbell <leecam@google.com>, Julien Tinnes <jln@google.com>, Mike Depinet <mdepinet@google.com>, James Morris <james.l.morris@oracle.com>, Andy Lutomirski <luto@amacapital.net>, Paolo Bonzini <pbonzini@redhat.com>, Paul Moore <paul@paul-moore.com>, Christoph Hellwig <hch@infradead.org>, Linux API <linux-api@vger.kernel.org>, LSM List <linux-security-module@vger.kernel.org>, fstests@vger.kernel.org Subject: Re: [PATCHv3 man-pages 3/3] open.2: describe O_BENEATH flag Date: Mon, 9 Mar 2015 15:16:34 +0000 [thread overview] Message-ID: <CAHse=S_kMkiV8hB5Y1=kVGCi3ZusRm5G=EyXhY_+PRycSt7GSw@mail.gmail.com> (raw) In-Reply-To: <54FDAF16.2030407@gmail.com> On Mon, Mar 9, 2015 at 2:32 PM, Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote: > On 03/09/2015 03:00 PM, David Drysdale wrote: >> Signed-off-by: David Drysdale <drysdale@google.com> > > Hi David, > > The text looks good insofar as it goes. But, it would be helpful > to have sentence or to that explains why this flag exists. > Could you add that, please? > > Thanks, > > Michael How about something like: This feature allows applications to be sure that the opened file is within the specified directory, regardless of the original source of the pathname argument. Some security-conscious pro‐ grams may further ensure this by imposing a system call filter (with seccomp(2)) that requires this flag for all open() opera‐ tions, so that the program cannot open files outside of speci‐ fied directories even if subverted. (Also, I realize that I somehow failed to notice that the flags are listed in alphabetical order, so I'll move the text up, as in the updated diff below). Thanks, David --- man2/open.2 | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/man2/open.2 b/man2/open.2 index 956531b24b26..ece1fa90775a 100644 --- a/man2/open.2 +++ b/man2/open.2 @@ -201,6 +201,43 @@ See for further details. See also BUGS, below. .TP +.B O_BENEATH " (since Linux 4.??)" +Ensure that the +.I pathname +is beneath the current working directory (for +.BR open (2)) +or the +.I dirfd +(for +.BR openat (2)). +If the +.I pathname +is absolute or contains a path component of "..", the +.BR open () +fails with the error +.BR EPERM. +This occurs even if ".." path component would not actually +escape the original directory; for example, a +.I pathname +of "subdir/../filename" would be rejected. +Path components that are symbolic links to absolute paths, or that are +relative paths containing a ".." component, will also cause the +.BR open () +operation to fail with the error +.BR EPERM. + +This feature allows applications to be sure that the opened file is +within the specified directory, regardless of the original source of the +.I pathname +argument. +Some security-conscious programs may further ensure +this by imposing a system call filter (with +.BR seccomp (2)) +that requires this flag for all +.BR open () +operations, so that the program cannot open files outside of +specified directories even if subverted. +.TP .BR O_CLOEXEC " (since Linux 2.6.23)" .\" NOTE! several other man pages refer to this text Enable the close-on-exec flag for the new file descriptor. @@ -984,6 +1021,13 @@ did not match the owner of the file and the caller was not privileged The operation was prevented by a file seal; see .BR fcntl (2). .TP +.B EPERM +The +.B O_BENEATH +flag was specified and the +.I pathname +was not beneath the relevant directory. +.TP .B EROFS .I pathname refers to a file on a read-only filesystem and write access was -- 2.2.0.rc0.207.ga3a616c -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-03-09 15:16 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-09 14:00 [PATCHv3 0/3] fs: add O_BENEATH flag to openat(2) David Drysdale 2015-03-09 14:00 ` [PATCHv3 1/3] " David Drysdale 2015-03-09 14:00 ` [PATCHv3 xfstests 2/3] generic: test openat and new O_BENEATH flag David Drysdale 2015-03-09 14:00 ` David Drysdale 2015-03-16 23:24 ` Dave Chinner 2015-03-16 23:24 ` Dave Chinner 2015-03-17 15:33 ` Kees Cook 2015-03-18 2:52 ` Dave Chinner 2015-03-18 2:52 ` Dave Chinner 2015-03-18 10:17 ` David Drysdale 2015-03-09 14:00 ` [PATCHv3 man-pages 3/3] open.2: describe " David Drysdale 2015-03-09 14:32 ` Michael Kerrisk (man-pages) 2015-03-09 15:16 ` David Drysdale [this message] 2015-03-09 15:16 ` David Drysdale 2015-03-09 15:54 ` 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='CAHse=S_kMkiV8hB5Y1=kVGCi3ZusRm5G=EyXhY_+PRycSt7GSw@mail.gmail.com' \ --to=drysdale@google.com \ --cc=ebiederm@xmission.com \ --cc=fstests@vger.kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=hch@infradead.org \ --cc=james.l.morris@oracle.com \ --cc=jln@google.com \ --cc=jorgelo@google.com \ --cc=keescook@chromium.org \ --cc=leecam@google.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mdepinet@google.com \ --cc=meredydd@senatehouse.org \ --cc=mtk.manpages@gmail.com \ --cc=paul@paul-moore.com \ --cc=pbonzini@redhat.com \ --cc=rickyz@google.com \ --cc=viro@zeniv.linux.org.uk \ --cc=wad@chromium.org \ /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.