linux-kernel - Re: patch to make Linux capabilities into something useful (v 0.3.1)

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: <20060908225118.GB877@clipper.ens.fr>
Date:	Sat, 9 Sep 2006 00:51:18 +0200
From:	David Madore <david.madore@....fr>
To:	Linux Kernel mailing-list <linux-kernel@...r.kernel.org>
Cc:	Pavel Machek <pavel@....cz>
Subject: Re: patch to make Linux capabilities into something useful (v 0.3.1)

On Fri, Sep 08, 2006 at 12:52:39PM +0200, Pavel Machek wrote:
> Well, you claim it is as safe as possible, and it is not quite. 

I claim "safe enough". :-)

> I can bet someone will get the fork() case wrong:
> 
> f = fork();
> kill(f);
> 
> fork will return -1, and kill will kill _all_ the processes.

Someone who writes code like that deserves to get all his processes
killed. :-p fork() can fail for a million reasons, some of which, on
most systems, can be provoked by a malicious attacker (such as filling
all available process slots).

> If you can find another uid to hijack, that other uid has bad
> problems. And I do not think you'll commonly find another uid to
> hijack.

How about another gid, then?  Should we reset all caps on sgid exec?

Ultimately a compromise is to be reached between security and
flexibility...  The problem is, I don't know who should make the
decision.

> And there are easier ways to get out of jail with your proposed
> capabilities: you do not restrict ptrace, so you can just ptrace any
> other process with same uid, and hijack it.

That's true.  The restrictions on process killing (which Serge
introduced) should probably be applied to ptrace() also.

> (You probably want to introduce CAP_REG_PTRACE).

Good idea.  I did, in version 0.4.2.

> Or just remove CAP_REG_XUID_EXEC when removing any other CAP_REG...?

Doable, but ugly (or so I think): there are many paths that set
caps...  A simpler solution would be to remove the test on
CAP_REG_SXID and instead test on all regular caps simultaneously.
Still, I really don't like the idea.

> It is not too bad; you'll usually not want restricted programs to exec
> anything setuid... (Do you have example where
> restricted-but-should-be-able-to-setuid-exec makes sense?)

Well, I could imagine that a paranoid sysadmin might want some users'
processes to run without this or that capability (perhaps
CAP_REG_PTRACE or some other yet-to-be-defined capability).  This
doesn't mean that they shouldn't be able to run a game which runs sgid
in order to write the score file.

-- 
     David A. Madore
    (david.madore@....fr,
     http://www.madore.org/~david/ )
-
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/