[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+tMVT2uQMP74KsYfvN-uFtQmjin-mON9gAs-qAMUq52Q@mail.gmail.com>
Date: Tue, 6 Jun 2017 21:10:43 -0700
From: Kees Cook <keescook@...omium.org>
To: Solar Designer <solar@...nwall.com>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: symlink/hardlink/FIFO restrictions
On Tue, Jun 6, 2017 at 2:55 PM, Solar Designer <solar@...nwall.com> wrote:
> The hardlink restrictions differ between -ow vs. grsecurity and upstream.
> In -ow, I had the check in vfs_link(). In grsecurity (oldest I checked
> now is grsecurity-2.1.11-2.4.35-200708071800), it's in sys_link() and
> later in sys_linkat(), which is also called by sys_link(). Upstream
> also has it right in the linkat() syscall function. Maybe there were
> good reasons not to do it in vfs_link(), but I am unaware of those.
> We need to know what currently happens and what we'd like to happen for
> other callers to vfs_link(), such as kernel nfsd and CRIU - do we want
> the restrictions to apply there? Maybe for some of those other callers,
> but not for all? Do the same checks work correctly when called from
> those other contexts or do we need revised checks there?
Hm, yeah, I don't remember sys_linkat() vs vfs_link() coming up during
review, but it's been a while. The nfsd thing is interesting... would
it be right to refuse a client's linkat based on the server's link
restriction sysctl? Hmm.
> As to the FIFO restrictions, those don't appear to have been merged
> upstream yet.
Do the FIFO restrictions exist in -ow too? I wonder what enabling that
protection might break... (better asked as "omg, what puts FIFOs in +t
directories?")
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
