linux-kernel - Re: [PATCH 1/3] switch_creds: Syscall to switch creds for file server ops

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 16 Oct 2013 20:52:58 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Jim Lieb <jlieb@...asas.com>, tytso@....edu, viro@...iv.linux.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	bfields@...hat.com, jlayton@...hat.com
Subject: Re: [PATCH 1/3] switch_creds:  Syscall to switch creds for file server ops

Al Viro <viro@...IV.linux.org.uk> writes:

> On Wed, Oct 16, 2013 at 06:18:16PM -0700, Eric W. Biederman wrote:
>
>> That doesn't look bad but it does need capable(CAP_SETUID) &&
>> capable(CAP_SETGID) or possibly something a little more refined.
>
> D'oh
>
>> I don't think we want file descriptor passing to all of a sudden become
>> a grant of privilege, beyond what the passed fd can do.
>
> Definitely.  And an extra ) to make it compile wouldn't hurt either...

There also appears to need to be a check that we don't gain any
capabilities.

We also need a check so that you don't gain any capabilities, and
possibly a few other things.

So I suspect we want a check something like:

if ((new_cred->securebits != current_cred->securebits)  ||
    (new_cred->cap_inheritable != current_cred->cap_inheritable) ||
    (new_cred->cap_permitted != current_cred->cap_permitted) ||
    (new_cred->cap_effective != current_cred->cap_effective) ||
    (new_cred->cap_bset != current_cred->cap_bset) ||
    (new_cred->jit_keyring != current_cred->jit_keyring) ||
    (new_cred->session_keyring != current_cred->session_keyring) ||
    (new_cred->process_keyring != current_cred->process_keyring) ||
    (new_cred->thread_keyring != current_cred->thread_keyring) ||
    (new_cred->request_keyring != current_cred->request_keyring) ||
    (new_cred->security != current_cred->security) ||
    (new_cred->user_ns != current_cred->user_ns)) {
	return -EPERM;
}

Eric

--
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/