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: <20061208211626.GA30754@sergelap.austin.ibm.com>
Date:	Fri, 8 Dec 2006 15:16:26 -0600
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org,
	Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH 0/2] file capabilities: two bugfixes

Quoting Casey Schaufler (casey@...aufler-ca.com):
> 
> --- "Serge E. Hallyn" <serue@...ibm.com> wrote:
> 
> > ...
> > The other is that root can lose capabilities by
> > executing files with
> > only some capabilities set.  The next two patches
> > change these
> > behaviors.
> 
> It was the intention of the POSIX group that
> capabilities be independent of uid. I would
> argue that the old bevavior was correct, that
> a program marked to lose a capability ought
> to even if the uid is 0.

Agreed, and if SECURE_NOROOT is set, that is what happens.
But by default SECURE_NOROOT is not set, in which case linux's
implementation of capabilities behaves differently for root.

Without this latest patch, with SECURE_NOROOT not set, what was
actually happening was that the kernel behaved as though
SECURE_NOROOT was not set so long as there was no
security.capability xattr, and always behaved as though
SECURE_NOROOT was set if there was an xattr.  That's inconsistent
and confusing behavior.

The worst part is that root can get around running the code
with limited caps by just copying the file and running the
copy.  So it adds no security benefit, and adds an
inconsistency/complication which could cause security risks.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ