Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 19 Jun 2011 17:34:35 +0400
From: Vasiliy Kulikov <>
Subject: Re: rlimit_nproc check

On Sun, Jun 12, 2011 at 06:28 +0400, Solar Designer wrote:
> Right.  Dealing with setuid() failing to drop privs yet returning, which
> many apps don't expect, is definitely something we (you) need to do
> under this project.  In Linux 2.4.x-ow, I simply do:
> --- linux-	2010-02-01 21:04:46 +0000
> +++ linux-	2010-02-18 14:04:42 +0000
> @@ -514,8 +514,10 @@ static int set_user(uid_t new_ruid, int 
>  	struct user_struct *new_user;
>  	new_user = alloc_uid(new_ruid);
> -	if (!new_user)
> +	if (!new_user) {
> +		force_sig(SIGSEGV, current);
>  		return -EAGAIN;
> +	}
>  	switch_uid(new_user);
>  	if(dumpclear)
> As an option, you could propose to revert that 8-year old change and
> introduce the check on execve().  Unrealistic?

I have slightly another idea.  Introduce mechanism (e.g. sysctl
variable) to make all capabilities dropping function cause SIGSEGV if
actual dropping process fails for any of several reasons.

The initial list should look like this:

    prctl(PR_CAPBSET_DROP, ...)
    prctl(PR_SET_SECCOMP, ...)

But any such list looks a bit not complete because there are many
different functions that might drop some capabilities in some
situations, like close(), *chdir(), rlimit(), nice(), fcntl(), ioctl(),
chroot(), which are, well, might fail in very common situations without
any actual secuity risk.

So, IMO this solution might not be enough consistent for upstream



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.