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]
Date: Tue, 21 May 2024 01:12:57 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Tycho Andersen" <tycho@...ho.pizza>, "Jonathan Calmels"
 <jcalmels@...0.net>
Cc: <brauner@...nel.org>, <ebiederm@...ssion.com>, "Luis Chamberlain"
 <mcgrof@...nel.org>, "Kees Cook" <keescook@...omium.org>, "Joel Granados"
 <j.granados@...sung.com>, "Serge Hallyn" <serge@...lyn.com>, "Paul Moore"
 <paul@...l-moore.com>, "James Morris" <jmorris@...ei.org>, "David Howells"
 <dhowells@...hat.com>, <containers@...ts.linux.dev>,
 <linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
 <linux-security-module@...r.kernel.org>, <keyrings@...r.kernel.org>
Subject: Re: [PATCH 3/3] capabilities: add cap userns sysctl mask

On Tue May 21, 2024 at 12:13 AM EEST, Tycho Andersen wrote:
> On Mon, May 20, 2024 at 12:25:27PM -0700, Jonathan Calmels wrote:
> > On Mon, May 20, 2024 at 07:30:14AM GMT, Tycho Andersen wrote:
> > > there is an ongoing effort (started at [0]) to constify the first arg
> > > here, since you're not supposed to write to it. Your usage looks
> > > correct to me, so I think all it needs is a literal "const" here.
> > 
> > Will do, along with the suggestions from Jarkko
> > 
> > > > +	struct ctl_table t;
> > > > +	unsigned long mask_array[2];
> > > > +	kernel_cap_t new_mask, *mask;
> > > > +	int err;
> > > > +
> > > > +	if (write && (!capable(CAP_SETPCAP) ||
> > > > +		      !capable(CAP_SYS_ADMIN)))
> > > > +		return -EPERM;
> > > 
> > > ...why CAP_SYS_ADMIN? You mention it in the changelog, but don't
> > > explain why.
> > 
> > No reason really, I was hoping we could decide what we want here.
> > UMH uses CAP_SYS_MODULE, Serge mentioned adding a new cap maybe.
>
> I don't have a strong preference between SETPCAP and a new capability,
> but I do think it should be just one. SYS_ADMIN is already god mode
> enough, IMO.

Sometimes I think would it make more sense to invent something
completely new like capabilities but more modern and robust, instead of
increasing complexity of a broken mechanism (especially thanks to
CAP_MAC_ADMIN).

I kind of liked the idea of privilege tokens both in Symbian and Maemo
(have been involved professionally in both). Emphasis on the idea not
necessarily on implementation.

Not an LSM but like something that you could use in the place of POSIX
caps. Probably quite tedious effort tho because you would need to pull
the whole industry with the new thing...

BR, Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ