4 ms·

I haven't used seccomp, but have recently been playing around with the Linux pledge port[1]. It has a very friendly UI, but I still struggled with allowing some

• ShowalkKama 3y ago
  >Digging through a mountain of strace output is tedious did you consider logging the syscalls invoked during normal usage with 'strace --output=/some/dir -f ...'? This + grep + uniq should make it really simple.
• eyberg 3y ago
  We too ended up adding pledge and unveil to Nanos. Seccomp and seccomp-bpf are indeed entirely way too limiting. It wasn't really designed for end app developers who are, imo, the ones that should be dictating the policy. The whole lack of pointer deref'ing makes it really difficult for application level developers to make policies that are easier to create. The promises arg in pledge, https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 , does a decent job of grouping related calls together but I think there is a ton of room to make all of this a lot better than it is today.
• Arch-TK 3y ago
  Pledge works well if the software developers implement it on their own application. It also works well if the software developers document what syscalls they rely on and what permissions they need. When it comes to retrofitting something like pledge (or seccomp) into an existing application when you've not developed it and/or can't easily tell what syscalls are being called then it's always a nightmare. It doesn't really matter if it's pledge or seccomp at that point (although undoubtedly seccomp is far harder to make use of), if you're doing this kind of security by retroactive whitelist, you're going to have trouble making it work. It's going to take time and effort to implement.
  • heroprotagonist 3y ago
    There's no tracing tool to build policy with pledge? Seems like an obvious area to add functionality if it doesn't exist. Commercial tools have had it for a long time.. even automatic profiling. Either explicitly profile during a test stage, which is best, or profile-on-first-observation. In the full automatic mode, which is not optimal but is least effort, any operation performed in the first XX minutes/hours/days are considered 'allowed behavior' and anything after that is denied. Then it will either enforce or 'wait-to-enforce' where enforcement mode only turns on if there are no policy violations in the next XX configurable units of time.
    • tedunangst 3y ago
      1. You really need to understand the application more than that. Does ls need network sockets? Sure does, if you have yp enabled. But this won't appear in your trace unless you trace in such an environment. (Although pledge on openbsd transparently handles this case for you.) 2. Just because a program makes a system call doesn't mean it should. Or should at that moment. A lot of late initialization can be done earlier for tighter policies. Auto traced policies tend to be extremely broad, permitting too much stuff.
  • rollcat 3y ago
    > When it comes to retrofitting something like pledge (or seccomp) into an existing application when you've not developed it and/or can't easily tell what syscalls are being called then it's always a nightmare. Quite the contrary. If the software in question has been written in a remotely sane way, adding some basic pledge restrictions is a matter of adding one line: pledge("stdio rpath whatever you need", NULL) - it usually goes somewhere in main, after setup() but before while(!quit). You can usually figure out the permission set within a few attempts, even without a very good understanding of the internals, as most (sane) programs will do only a couple of things: an httpd needs to accept connections, read static files, write logs, etc; a window manager needs to talk to X11, open font files, etc; of course there are also complex beasts like Chrome but that one has been done as well. The *real* challenge is breaking up a complex program (e.g. a streaming music player) into separate processes that are concerned with just one or two things, e.g. separate process to make requests over the network, a separate one to decode media, another to maintain an on-disk cache, and so on. Placing restrictions on these subprocesses is the easy part; figuring out where to draw these lines is what's hard. https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2
• tedunangst 3y ago
  Despite the availability of linux pledge, and frequent comments mentioning its existence, I'm not aware of many people using it.
  • jmprspret 3y ago
    I think it would acquire more usage if it was part of mainline Linux distros. As far as I can tell people must feel like this is some kind of optional, nonstandard thing. It works well with openbsd because its standard, and most if not all openbsd packages make use of it Though maybe I'm misunderstanding how Linux pledge works. I'm only familiar with the openbsd usage of it