On Fri, Jun 26, 2020 at 10:18 PM james <gar...@verizon.net> wrote:
>
> On 6/26/20 4:40 PM, Rich Freeman wrote:
> > Removing the group doesn't actually make things more secure, because
> > processes can use a gid even if it doesn't exist in /etc/groups.
> > Effectively any POSIX system has every uid/gid available even if there
> > is no /etc/passwd at all.
>
> And that is coded into the parts of the kernel, we cannot eliminate?
> Typical sploits?
>
> Curiously, a bit deeper explanation?
So, ultimately a uid/gid is just a number, and a field in a couple of
tables. Inodes have them, and processes have them. There might be
other things that have them that I'm not thinking of, but those are
probably the main two.
If a process wants to send signals to another process the uids have to
match, or it must have a capability to break this rule. If a process
wants to read a file, the uid/gid/permissions/ACLs/etc must correspond
appropriately. I'm sure there are a bunch of other system calls where
uids/gids matter as well.
The field that stores the IDs has a certain size, and thus any number
within the expressible range is valid. You can't "get rid" of a UID
any more than you can ban the number 13. However, since the logic is
based on matching it really doesn't matter much - if you launch a
process with a UID you intended to be "unused" it basically is
completely isolated as far as the filesystem and other processes go
since its UID doesn't match anything else (it could still touch world
read/writeable files, but that is true if it ran under a UID you
preferred that it use).
The files /etc/passwd and /etc/group are used by various system
programs to map these IDs to human-readable names, but they really
aren't part of how the kernel works. Just about any command that can
take a username can take a user ID, and if you want to really drive
people crazy go ahead and try using numeric usernames (I believe the
IDs take precedence in command lines).
So, if you deleted /etc/{passwd,group,shadow} you could still have a
"perfectly working" linux userspace, but commands like login wouldn't
work as those use usernames and of course there would be no mapping to
passwords. However init would still run as uid 0, and it could launch
processes with other uids, and those processes would have regular
filesystem behavior. It wouldn't be POSIX and various things might
break, but you could have a name-less userspace just fine on linux.
The kernel itself never looks at /etc/shadow and so on - it just sees
numeric IDs. Android is an example of an OS that makes some
substantial changes in userspace to how things like UIDs are
traditionally used (that, and the OOM killer).
Most things associated with users/groups in linux are conventions
implemented in userspace.
But, as I said, using more uids/gids in general means having more
separation. In general it only increases security, with the caveat
that it does potentially make auditing more complex.
--
Rich
