linux-kernel - Re: [PATCH] fs: hardlink creation restrictions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5jL-NZP9At16q-b6biszMAWQQ4HLzW3cHDQUf0m7PGwGbQ@mail.gmail.com>
Date:	Sun, 19 Feb 2012 09:45:12 -0800
From:	Kees Cook <keescook@...omium.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Randy Dunlap <rdunlap@...otime.net>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH] fs: hardlink creation restrictions

On Sun, Feb 19, 2012 at 4:49 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * Kees Cook <keescook@...omium.org> 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@...e.hu>

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/