Re: [PATCH] fs: hardlink creation restrictions

[Kees Cook <keescook@xxxxxxxxxxxx>]

On Sun, Feb 19, 2012 at 4:49 AM, Ingo Molnar <mingo@xxxxxxx> wrote:
>
> * Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>
>> This is the other half of link restrictions, now that symlink
>> restriction has landed in -mm.
>
> Nice features!

Thanks!

>> @@ -300,9 +302,29 @@ config PROTECTED_STICKY_SYMLINKS_ENABLED
>>         via /proc/sys/kernel/protected_sticky_symlinks.
>>
>>  config PROTECTED_STICKY_SYMLINKS_ENABLED_SYSCTL
>> -     depends on PROTECTED_STICKY_SYMLINKS
>> +     depends on PROTECTED_LINKS
>>       int
>>       default "1" if PROTECTED_STICKY_SYMLINKS_ENABLED
>>       default "0"
>>
>> +config PROTECTED_NONACCESS_HARDLINKS_ENABLED
>> +     depends on PROTECTED_LINKS
>> +     bool "Disallow hardlink creation to non-accessible files"
>> +     default y
>> +     help
>> +       Solve ToCToU hardlink race vulnerabilities by permitting hardlinks
>> +       to be created only when to a regular file that is owned by the user,
>> +       or is readable and writable by the user. Also blocks users from
>> +       "pinning" vulnerable setuid/setgid programs from being upgraded by
>> +       the administrator.
>> +
>> +       When PROC_SYSCTL is enabled, this setting can also be controlled
>> +       via /proc/sys/kernel/protected_nonaccess_hardlinks.
>
> I'd add a:
>
>        See Documentation/sysctl/fs.txt for details.
>
> line as well.

Good call.

>> +config PROTECTED_NONACCESS_HARDLINKS_ENABLED_SYSCTL
>> +     depends on PROTECTED_LINKS
>> +     int
>> +     default "1" if PROTECTED_NONACCESS_HARDLINKS_ENABLED
>> +     default "0"
>
> Naming nit: how about dropping the _NONACCESS/_nonaccess names
> complete and turn it into protected_hardlinks? The longer
> variant is not any better descriptive, and needlessly longer.
>
> The PROTECTED_SYMLINKS/PROTECTED_HARDLINKS naming is thus also
> nicely symmetric.

Yeah, this really does look much better. I had opted for extreme
verbosity, but I would agree: it's not really called for here.

>> +#ifdef CONFIG_AUDIT
>> +     if (error) {
>> +             struct audit_buffer *ab;
>> +
>> +             ab = audit_log_start(current->audit_context,
>> +                                  GFP_KERNEL, AUDIT_AVC);
>> +             audit_log_format(ab, "op=linkat action=denied");
>> +             audit_log_format(ab, " pid=%d comm=", current->pid);
>> +             audit_log_untrustedstring(ab, current->comm);
>> +             audit_log_d_path(ab, " path=", old_path);
>> +             audit_log_format(ab, " dev=");
>> +             audit_log_untrustedstring(ab, inode->i_sb->s_id);
>> +             audit_log_format(ab, " ino=%lu", inode->i_ino);
>> +             audit_log_end(ab);
>> +     }
>> +#endif
>
> Small detail: don't these audit methods map to nothing on
> !CONFIG_AUDIT, allowing the #ifdef to be dropped? (if not then
> it should really be so.)

Ah-ha; a more careful look at audit.h agrees. :) I'll adjust this as well.

> Acked-by: Ingo Molnar <mingo@xxxxxxx>

Thanks for the review,

-Kees

-- 
Kees Cook
ChromeOS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/