From: Andy Lutomirski <email@example.com> To: Jann Horn <firstname.lastname@example.org> Cc: Al Viro <email@example.com>, Linux API <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Linux FS Devel <email@example.com> Subject: Re: new ...at() flag: AT_NO_JUMPS Date: Mon, 1 May 2017 12:37:49 -0700 [thread overview] Message-ID: <CALCETrW1uyDa7++T_SXOYUd745dB+xyqzd=61PU+iNeUzCSdAQ@mail.gmail.com> (raw) In-Reply-To: <CAG48ez0wccvQ5i+XN_Q_yA9_ZwSaGb-W+zky0KQb_GU=9G+MSw@mail.gmail.com> On Mon, May 1, 2017 at 10:36 AM, Jann Horn <firstname.lastname@example.org> wrote: > On Sun, Apr 30, 2017 at 12:04 AM, Al Viro <email@example.com> wrote: >> New AT_... flag - AT_NO_JUMPS >> >> Semantics: pathname resolution must not involve >> * traversals of absolute symlinks >> * traversals of procfs-style symlinks >> * traversals of mountpoints (including bindings, referrals, etc.) >> * traversal of .. in the starting point of pathname resolution. >> >> All of those lead to failure with -ELOOP. Relative symlinks are fine, >> as long as their resolution does not end up stepping into the conditions >> above. >> >> It guarantees that result of successful pathname resolution will be on the >> same filesystem as its starting point and within the subtree rooted at >> the starting point. >> >> Right now I have it hooked only for fstatat() and friends; it could be >> easily extended to any ...at() syscalls. Objections? > > Oh, nice! > > It looks like this is somewhat similar to the old O_BENEATH proposal, > but because the intentions behind the proposals are different > (application sandboxing versus permitting an application to restrict its > own filesystem accesses), the semantics differ: AT_NO_JUMPS > doesn't prevent starting the path with "/", but does prevent mountpoint > traversal. Is that correct? > I missed that. I think that AT_HOTEL_CALIFORNIA or whatever we call it should disallow even explicit absolute paths. If I do: openat([fd to /var/www], "possibly untrusted path here", AT_HOTEL_CALIFORNIA, O_WHATEVER); I should not have to separately verify that the path doesn't start with "/" to make sure that I don't escape. There's a big added advantage of this approach, too: I could write a seccomp rule that only lets me call openat() with this new flag set, and now I can't escape. > I think that, as Andy mentioned, it might make sense to split out (or > even remove?) the prevention of mountpoint traversal. A user who > can create visible mountpoints needs to have capabilities over the > mount namespace the file descriptor refers to already. Agreed. There's a big difference between the admin bind-mounting /etc into /var/www and some web app putting a symlink to /etc into /var/www.
next prev parent reply other threads:[~2017-05-01 19:38 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-29 22:04 Al Viro 2017-04-29 23:17 ` Andy Lutomirski 2017-04-29 23:25 ` Al Viro 2017-04-30 1:13 ` Andy Lutomirski 2017-04-30 4:38 ` Matthew Wilcox 2017-04-30 16:10 ` Al Viro 2017-05-01 4:52 ` Andy Lutomirski 2017-05-01 5:15 ` Al Viro 2017-05-01 17:36 ` Jann Horn 2017-05-01 19:37 ` Andy Lutomirski [this message] 2017-05-05 0:30 ` Al Viro 2017-05-05 0:44 ` Andy Lutomirski 2017-05-05 1:06 ` Al Viro 2017-05-05 1:27 ` Linus Torvalds 2017-05-05 3:00 ` Al Viro 2017-05-05 4:01 ` Linus Torvalds 2017-05-05 4:31 ` Andy Lutomirski 2017-05-05 2:47 ` Jann Horn 2017-05-05 3:46 ` Linus Torvalds 2017-05-05 4:39 ` Al Viro 2017-05-05 4:44 ` Andy Lutomirski 2017-05-05 20:04 ` Eric W. Biederman 2017-05-05 20:28 ` Eric W. Biederman 2017-05-08 19:34 ` Mickaël Salaün 2017-05-18 8:50 ` David Drysdale 2017-09-10 20:26 Jürg Billeter
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='CALCETrW1uyDa7++T_SXOYUd745dB+xyqzd=61PU+iNeUzCSdAQ@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: new ...at() flag: AT_NO_JUMPS' \ /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: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).