linux-kernel - Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3

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: <20071119231644.GA26373@sergelap.austin.ibm.com>
Date:	Mon, 19 Nov 2007 17:16:44 -0600
From:	"Serge E. Hallyn" <sergeh@...ibm.com>
To:	Chris Friedhoff <chris@...edhoff.org>
Cc:	Serge E Hallyn <sergeh@...ibm.com>,
	linux-security-module@...r.kernel.org,
	Stephen Smalley <sds@...ch.ncsc.mil>,
	Andrew Morgan <morgan@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3

Quoting Chris Friedhoff (chris@...edhoff.org):
> Hello Serge,
> 
> just to let you know: with 2.6.24-rc3 I have the same problem.

Ok, so here is the flow.

First off, using runlevel 5 on FC7, using 'log out' correctly brings
you back to a new login prompt.  Your problem is starting in runlevel
3, and typing 'xinit .xinitrc';  when you exit your wm, xinit is not
allowed to kill X so you don't get back to your console.

First comment is, as you point out on your homepage, you could
	setfcaps -c cap_kill+p -e /usr/bin/xinit
Then xinit is allowed to kill X.  Yes xinit forks and execs a
user-writable script, but of course upon the exec to start the script
cap_kill is lost, so the user can't abuse this.

Since you pointed this out on your homepage, I have to assume you've
decided you don't want to give cap_kill to xinit?

My other question is - do we want to maintain this signal restriction?
So long as a privileged process isn't dumpable, is it any more dangerous
for user hallyn to kill capability-raised process owned by hallyn than
it is to kill a setuid process started by hallyn?  If we decide no, then
maybe we should remove cap_task_kill() as well as the cap_task_setnice(),
cap_task_setioprio(), cap_task_setscheduler()?

Or maybe i've just forgotten a compelling scenario...

thanks,
-serge
-
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/