3 ms·

What are your suggestions or projects for improving the state of Linux and Unix security?

• chasil 5y ago
  Let's take this basic example: # ll /usr/bin/passwd -rwsr-xr-x. 1 root root 36760 Feb 16 2020 /usr/bin/passwd The setuid permission on that program allows it to escalate to root for part of it's runtime. Why are we doing this? I could make a new "passwd" user, and assign it a non-zero UID and GID, setuid to that user instead, making it own this file: # ll /etc/passwd -rw-r--r--. 1 root root 3346 Apr 8 2021 /etc/passwd UNIX in general seems to have a root fixation on setuid. Both passwd and shadow users should exist, with separate roles and privileges, and root users should not be held in either of their databases.
  • rascul 5y ago
    I kinda like this idea, although I'm unlikely to implement it (at least in the near future). A question though. > root users should not be held in either of their databases Where would you propose keeping the information for UID 0?
    • chasil 5y ago
      How about: /etc/passed.root /etc/shadow.root /etc/group.root I don't know if the handling of the "wheel" group should be any different. It's still enforced on OpenBSD for su.
  • deleted 5y ago
    [deleted]
  • mgsouth 5y ago
    Um, if you can compromise "passwd" it's game over; you are root equivalent. Looking at other suids in /bin... Compromise mount, game over. Compromise su, game over. arping? ping? Dunno; they can generating normally-prohibited packets. umount? Hmmm.... feels like some kind of clever trick lurking here. As for kernel subsystems, there's very little which cannot lead to full system compromise, either directly or indirectly by tricking a user.