Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 Jun 2017 21:10:43 -0700
From: Kees Cook <>
To: Solar Designer <>
Cc: "" <>
Subject: Re: symlink/hardlink/FIFO restrictions

On Tue, Jun 6, 2017 at 2:55 PM, Solar Designer <> 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


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.