Conversation

Notices

1. Embed this notice
   Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Sunday, 10-Sep-2023 20:44:24 JST Haelwenn /элвэн/ :triskell:
   I quite feel like setuid(2) kind of syscalls ought to be deprecated, it shouldn't be left to ~random system programs to provide a clean or even appropriate OS runtime.
   
   Instead you probably should have something in the style of posix_spawn with few more parameters for say authentication results (ie. user login) or capabilities (ie. daemon with privilege separation).
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Sunday, 10-Sep-2023 20:53:01 JST Haelwenn /элвэн/ :triskell:

     in reply to

     Combine that with the wish to have things like audit logs, you’d probably end up with something bug-prone if you were to strace setuid(2) usage with enough contextual information.

     (And there’s the thing where setting a non-shell program in /etc/passwd isn’t a restriction but pretty much just a preference where you hope everything respects it)

   • Embed this notice
     Hugo 雨果 (whynothugo@fosstodon.org)'s status on Sunday, 10-Sep-2023 21:04:56 JST Hugo 雨果

     in reply to

     @lanodan Usually a privileged daemon is a much better approach. We just need people to write those daemons (and reference clients for them).

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Sunday, 10-Sep-2023 21:04:56 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Hugo 雨果
     @whynothugo Which leaves you with pretty much the same problem: Access is left to random stuff on your system and can't easily be controlled & audited at ~one place.
     
     And given how bad a broken parser can fail (even in memory-safe languages, for example logic errors are a thing) it's not the kind of thing where I'd be much confident in.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Sunday, 10-Sep-2023 21:29:00 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • LEdoian
     @ledoian If your brain model is Linux, yeah, it's probably done for.
     BSD maybe less so.
     
     And libc is no place to put enforcements in, only thing the libc needs to do is provide userland functions and *maybe* syscall wrappers.
     Because otherwise anything that's not using the code in your preferred libc would be left open, setuid isn't even only called by programs written in C.
   • Embed this notice
     LEdoian (ledoian@pleroma.ledoian.cz)'s status on Sunday, 10-Sep-2023 21:29:02 JST LEdoian

     in reply to

     @lanodan I guess that would need to be in userspace, though. IIRC kernel does not have any idea of “appropriate runtime”, nor it wants to enforce particular choices… So maybe keep setuid(2), but allow restricting it to a specific process?

     But yeah, having a single reusable implementation for “change the user in a sane way” (possibly in libc) would be so much better, not having to think about all the other nuances like saved UIDs, groups, environment, capabilities, … (This would probably help even setuid (u+s) programs being less bug-prone.)

     (btw, the shell in /etc/passwd is IIRC completely unprivileged (tested with an interactive Python as a shell). And even though, some distributions will only allow login if using shell from /etc/shells)

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Sunday, 10-Sep-2023 21:31:15 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • LEdoian
     @ledoian At least on my machines I setup nftables to forbid root from having network access except for ssh.
     And yeah I think the user for services when unspecified should be "nobody".
   • Embed this notice
     LEdoian (ledoian@pleroma.ledoian.cz)'s status on Sunday, 10-Sep-2023 21:31:16 JST LEdoian

     in reply to

     • LEdoian

     @lanodan tbh, completely privileged processes should probably die. There should be as few processes with full capabilities as possible. That is not the state currently, IIRC many services still run under full root even when they do not need to change users, access network, …

     If only a few processes got e.g. cap_setuid, it would be far more easy to check their behaviour.

     (And yes, since capabilities are Linux-specific, this would be complicated)

   • Embed this notice
     Hugo 雨果 (whynothugo@fosstodon.org)'s status on Tuesday, 12-Sep-2023 00:38:39 JST Hugo 雨果

     in reply to

     @lanodan It you expose all these services via unix sockets, then you can control access to them in one place: via file system access (eg: restricting access to file system).

     I’m not sure if this is in line to what you’re referring to with “controlling them in one place”.

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Tuesday, 12-Sep-2023 00:38:39 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Hugo 雨果

     @whynothugo By one place I mean more like an authentication server which would have at least as much metadata as /etc/{passwd,group} does if not more (say for restrictions).

     And while the filesystem is fine in many situations, you end up with pretty poor ACLs and fd-passing in Unix is quite second-class (for example sudo/doas should be able to have a mode where it only opens a file and passes the file descriptor to a command that would be ran as the original user, sadly the way fds are done don’t easily allow this to happen without modifying all program you’d need to use it with).

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Tuesday, 12-Sep-2023 00:59:32 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Hugo 雨果
     @whynothugo I can't really say it's well supported when it feels like part of the architecture is missing, there's no common/dedicated way to advertise fds.
     Which is quite why it's not just patching a bunch of software like you could do when a new API comes in, as said API is not really here.
   • Embed this notice
     Hugo 雨果 (whynothugo@fosstodon.org)'s status on Tuesday, 12-Sep-2023 00:59:33 JST Hugo 雨果

     in reply to

     @lanodan Passing fds across processes is very well supported on Unix/Linux in general. What’s missing is commands that take an fd as input (and I agree here that this deficiency is a bad thing). Do note that commands can be fixed one program at a time.

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Tuesday, 12-Sep-2023 01:04:28 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Hugo 雨果
     @whynothugo I don't think that would need to happen, quite like how checks for a file is only done when opened thanks to fds simply referring to data in a trusted environment (kernel or filesystem-daemon), the session once ~opened could be seen as trusted.
     
     Or how for network services you don't have checks with LDAP/SSO all the time, specially when connections are kept for long periods of time.
   • Embed this notice
     Hugo 雨果 (whynothugo@fosstodon.org)'s status on Tuesday, 12-Sep-2023 01:04:29 JST Hugo 雨果

     in reply to

     @lanodan And what exactly would this authentication server do? Do processes need to go through it every time they open a resource?