Hacker News Reader

Ironically, polkit is designed to avoid the need to have suid binaries, since it allows other programs to obtain restricted privileges without full suid. The problem is, polkit itself still needs suid to hand out privileges to other programs.

Yes and no, applications integrated with Polkit need to have privileges (usually by running as root). Polkit itself doesn't need any privileges since it's just a framework for programs that have elevated privileges to ask if a user is allowed to use them.

pkexec a program bundled with but not really part of Polkit is suid as the method it uses to gain elevated privileges rather than running a daemon.

I don't really understand your point. The kernel, cryptographic primitives, and device drivers also need to be developed really, really carefully. Some things require more care than others. What would be the alternative?

It seems like a good first goal would be to dramatically reduce the size of the code base you need to trust (especially complex code with high privilege), and focus on verifying the correctness of that code base. Then, have fine-grained encapsulation mechanisms for things that do need some level of privilege, and especially avoid conflating "can administer the system" and "can access all user data" levels of privilege.

As an example, although one that practically seems to have turned out harder to do than the authors expected, take a look at HiStar: http://www.scs.stanford.edu/histar/

Fine-grained sandboxing. Memory-safe languages. Safer syscalls (e.g. returning EFAULT when calling "execve(pointer to null array)").

There are lots of ways to improve the current state of security.

> Unfortunately, instead of seeing the absurdity of that situation, many people have gone all "no true Scotsman" on it. "If you were a real Unix Developer then you wouldn't make mistakes like that." We don't need no stinking tools, we're Real Programmers.

That is the problem. Unix, and the 'philosophy'.

I used to like it, but it is over half a century old and as well as everything 'unix-like' it was not designed for security, especially the C programming language. Thus, with everything 'unix-like', they have imported all the mistakes with it. The same with the legacy like X11, allowing root to modify system files, etc.

Unix is dead. Might need to move on from such prehistoric systems to ones that are designed for security that are not 'Unix'.

Isn't it more of a slippery slope? I want to be able run whatever I want on my system. If I get malicious code, who's fault is it? Maybe my browsing habits, the tasks I want done, the time I can spend on roling my own, the documentation (haha, what documentation), the schools, or the government and AT&T? Who is this real Unix Developer? The Linux Kernel has a stelar track record, just the towers of complexity built around it are growing like the weeds. The kernel isn't making it easy, hardware developers don't play nice, and every one wannabe expert wants it to be just working.

There's the actual "No True Scotsman", because capability based kernels exist for a long time now. Yet, users want something to work with, actual software that needs to be written, that doesn't even have to be in C.

The expressed sentiment is entirely independent of the domain. You simply need to know what you are doing or things won't move forward. It's only consequential that those whom rely on Unixoid systems for whichever reason do express this sentiment in terms of those systems.

The alternative are walled gardens, where criticizm is impossible. Because with secure boot and the like it would require breaking the system to take control.

Ironically, Multics did continue without Bell Labs and not surprisingly DoD security assessment for it was higher than UNIX with praise for their use of PL/I in preventing memory corruption bugs.

But it wasn't available as free tapes for universities to play with, so....

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

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.

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?

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.

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.

Your loaded premise is that the "tooling, verification, testing" would catch this. Can you illustrate how?