Re: Hard link creation witout write access

[Taylor R Campbell]

[trimming tech-userlevel and tech-kern from cc list to avoid
cross-posting the entire thread]

> Date: Thu, 7 Sep 2023 11:53:56 + (UTC)
> From: RVP 
> 
> On Thu, 7 Sep 2023, Taylor R Campbell wrote:
> 
> > I think we should have these knobs on by default, but of course in
> > principle that might break existing configurations.  So maybe we could
> > put it in the default /etc/sysctl.conf -- that way you only get it on
> > upgrade if you merge updates to /etc.
> 
> I played with this after christos@ added the knobs last year[1], and then
> sort(1) broke badly. See PR 56775. Expect further squalls if this is turned
> on by default.

That suggests the semantics we've implemented for the sysctl knobs is
not quite right:

if (hardlink_check_uid && kauth_cred_geteuid(cred) != va.va_uid)
goto checkroot;

if (hardlink_check_gid && kauth_cred_groupmember(cred, va.va_gid) != 0)
goto checkroot;

It seems to me the rule should be:

1. If you own the file you can make hard links.
2. If you are in the file's group and the file is group-writable you
   can make hard links.
3. Maybe if the file is other-writable you can make hard links.

The problem with sort in /tmp is that hardlink_check_gid requires you
to be in the file's group _even if you own the file_, which is also a
bonkers restriction.

Hard link creation witout write access

[Taylor R Campbell]

Today I learned that you can create hard links to a file you don't own
and can't write to or even read from:

$ su -l root -c 'touch /tmp/foo && chmod 600 /tmp/foo'
$ ln /tmp/foo /tmp/bar

This strikes me as bonkers and a likely source of security issues.

POSIX says:

> The implementation may require that the calling process has
> permission to access the existing file.
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/link.html

So this behaviour is allowed by POSIX but it would also be allowed to
make this fail with EACCES.  Unclear whether POSIX means ownership,
group membership, write access, or read access, but unless a POSIX
language lawyer can cite chapter & verse for the specific definition
of `has permission to access', I think this means the implementation
is allowed to apply any of those access rules?

Apparently we have sysctl knobs

security.models.extensions.hardlink_check_uid
security.models.extensions.hardlink_check_gid

to prohibit this bonkers linking, by prohibiting anyone but the owner
(hardlink_check_uid) or members of the group (hardlink_check_gid) from
creating hard links.  But the knobs are off by default.

Linux has a knob fs.protected_hardlinks which, if set, requires the
user to own or have write access to the file.

I think we should have these knobs on by default, but of course in
principle that might break existing configurations.  So maybe we could
put it in the default /etc/sysctl.conf -- that way you only get it on
upgrade if you merge updates to /etc.

Thoughts?