Ya'll need to discover pledge(2), unveil(2) and privilege separation.
https://twitter.com/majek04/status/1034759172041129984 …
-
-
Linux has seccomp something like the pledge model, but sadly it doesn't work well when you don't control the whole implementation stack.
-
Yeah, doesn't really support the incremental dropping mechanics either, just a single policy to rule them all, nothing preventing going to other way either.
-
All aspects of a good privilege model should be incremental and irreversible drop. (No suid or setcap, etc.) With that you can make chroot, all namespace type operations unprivileged and safe.
End of conversation
New conversation -
-
-
How do you feel about capabilities attached to file descriptors, like Capsicum in FreeBSD does?
-
Bad. Privs should be drop-only, no way to add once dropped.
-
I am not particularly experienced in this area, so I'd like to learn why would it be bad. An eg, the parent process passes a R/W fd to only the files the child needs to write to, and then make everything else R/O.
-
It would also be nice if you can point me at some doco on this stuff, most of what I read is system specific hence a bit opinionated (Linux people think seccomp is better, OpenBSD people would say pledge/unveil is, I hope you get my point :))
-
Capability Myths Demolished http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf … is pretty good at explaining capability systems; it predates Capsicum and doesn't directly apply to the capability-as-fd hybrid model but gives a good overview of the concepts
-
Capsicum is like snakeoil, a name drop into conversations about security. With very few practical applications fully taking advantage of its "capabilities". And the ones in the past that perhaps did, *cough* (where's chrome?) are vapourware & not maintained. Sorry, not buying it.
-
Chrome pledges by default today, and has for some time. unveil(2) is also ready for testing and can be easily enabled. Capsicum patches never made it into FreeBSD ports. The examples elsewhere basically fiddle with a few descriptors, not clear how they're making things "secure".
-
Compare: https://github.com/openssh/openssh-portable/blob/master/sandbox-capsicum.c … To: https://github.com/openssh/openssh-portable/blob/master/sandbox-seccomp-filter.c … https://github.com/openssh/openssh-portable/blob/master/sandbox-darwin.c …https://github.com/openssh/openssh-portable/blob/master/sandbox-pledge.c …
- 4 more replies
New conversation -
-
-
Someone correct me if I'm wrong, but I think what happened was this: POSIX realized root was stupid, and switched to making "appropriate privileges" implementation-defined. Linux geeks somehow misread that as POSIX adopting their (copied from somewhere?) capabilities model.
-
There's some text in the Rationale document on it: http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html#tag_21_03_00_01 …
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.