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-next>] [day] [month] [year] [list]
Date: Sat, 17 Feb 2024 15:56:40 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	lsf-pc@...ts.linux-foundation.org
Subject: [LSF TOPIC] beyond uidmapping, & towards a better security model

AKA - integer identifiers considered harmful

Any time you've got a namespace that's just integers, if you ever end up
needing to subdivide it you're going to have a bad time.

This comes up all over the place - for another example, consider ioctl
numbering, where keeping them organized and collision free is a major
headache.

For UIDs, we need to be able to subdivide the UID namespace for e.g.
containers and mounting filesystems as an unprivileged user - but since
we just have an integer identifier, this requires complicated remapping
and updating and maintaining a global table.

Subdividing a UID to create new permissions domains should be a cheap,
easy operation, and it's not.

The solution (originally from plan9, of course) is - UIDs shouldn't be
numbers, they should be strings; and additionally, the strings should be
paths.

Then, if 'alice' is a user, 'alice.foo' and 'alice.bar' would be
subusers, created by alice without any privileged operations or mucking
with outside system state, and 'alice' would be superuser w.r.t.
'alice.foo' and 'alice.bar'.

What's this get us?

Much better, easier to use sandboxing - and maybe we can kill off a
_whole_ lot of other stuff, too.

Apparmour and selinux are fundamentally just about sandboxing programs
so they can't own everything owned by the user they're run by.

But if we have an easy way to say "exec this program as a subuser of the
current user..."

Then we can control what that program can access with just our existing
UNIX permission and acls.

This would be a pretty radical change, and there's a number of things to
explore - lots of brainstorming to do.

 - How can we do this without breaking absolutely everything? Obviously,
   any syscalls that communicate in terms of UIDs and GIDs are a
   problem; can we come up with a compat layer so that most stuff more
   or less still works?

 - How can we do this a way that's the most orthogonal, that gets us the
   most bang for our buck? How can we kill off as much security model
   stupidity as possible? How can we make sandboxing _dead easy_ for new
   applications?

Cheers,
Kent

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ