This interface makes a system call at run time to reduce privileges. I wonder if there is a way to do this statically and automatically, either with some header file magic, or by analyzing the symbols in the executable: just assume at link time that any system calls it makes (and only those) are allowed.
A subsystem to restrict programs into a “reduced feature operating model”
41–50 of 101 posts
Re: A subsystem to restrict programs into a “reduced feature operating model”
#42For comparison, the man-page for FreeBSD's capsicum API: http://mdoc.su/f/capsicum.4.
Re: A subsystem to restrict programs into a “reduced feature operating model”
#43This won't work for programs that allow for plugins, which are arguably those that need the most protection. Programs don't generally know what permissions plugins when they are compiled.
Could you provide examples? The stuff I'm thinking of that would plugin to Firefox or Photoshop probably do things that would already be allowed (read/write files, allocate memory, access network). Either way this seems like an extremely simple way to lock down all the little command line utilities and small programs that make up a working unix system, so that if someone does get arbitrary command execution by other…
think more like emacs or vim. plugins can add any number of things that isnt just file read/write. they can add new syscalls for a built in debugger (ptrace, strace, etc.) or even add an opengl layer for coding in 3d.
Re: A subsystem to restrict programs into a “reduced feature operating model”
#44This sounds very similar to code access security (CAS) that Microsoft's CLR had from around 2000 (but at the OS level rather than the VM level).
Re: A subsystem to restrict programs into a “reduced feature operating model”
#45So, do I have it right that this is effectively a way of a program being able to declare to the operating system "I shouldn't ever do "? Because, if so, that makes a whole lot of sense. (Adding security "for free" generally does). This could conflict with on-the-fly upgrades, though. If it turns out that some later version of your program does in fact require , then you'll have to kill and restart the process as oppo…
It can also be used by a parent process to limit the functionality of a child process, by calling tame() after fork() and before exec(). I can imagine this being used with some a "tame" command in the shell to run untrusted programs. Of course I don't know how thorough the sandboxing is, and I wouldn't trust it to make unsafe programs completely safe.
> Of course I don't know how thorough the sandboxing is, and I wouldn't trust it to make unsafe programs completely safe.
That's the best part about OpenBSD -- the APIs may not be binary or even source-code compatible between the releases, but the source code is usually as readable and as clear as it gets.
Re: A subsystem to restrict programs into a “reduced feature operating model”
#46Earlier quoted context omitted.
Could you provide examples? The stuff I'm thinking of that would plugin to Firefox or Photoshop probably do things that would already be allowed (read/write files, allocate memory, access network). Either way this seems like an extremely simple way to lock down all the little command line utilities and small programs that make up a working unix system, so that if someone does get arbitrary command execution by other…
think more like emacs or vim. plugins can add any number of things that isnt just file read/write. they can add new syscalls for a built in debugger (ptrace, strace, etc.) or even add an opengl layer for coding in 3d.
That's basically what I meant, thanks for explaining it clearly.
Re: A subsystem to restrict programs into a “reduced feature operating model”
#47I can't see where in this patch forked children inherit the `ps_tame` from the parent process. I don't know this kernel at all but it seems like something like this should be in sys/kern/kern_fork.c
pr->ps_tame = parent->ps_tame
Re: A subsystem to restrict programs into a “reduced feature operating model”
#48I can't see where in this patch forked children inherit the `ps_tame` from the parent process. I don't know this kernel at all but it seems like something like this should be in sys/kern/kern_fork.c pr->ps_tame = parent->ps_tame Otherwise tamed processes could just fork a process to do things they've declared that they won't do.
A tamed process cannot even call fork(2) unless the TAME_PROC flag is passed, in which case I'd assume the child process would then inherit a copy from the parent as part of a normal fork(2) operation. It can be later revoked by the child, but it may want to keep it for kill(2).
Re: A subsystem to restrict programs into a “reduced feature operating model”
#49I can't see where in this patch forked children inherit the `ps_tame` from the parent process. I don't know this kernel at all but it seems like something like this should be in sys/kern/kern_fork.c pr->ps_tame = parent->ps_tame Otherwise tamed processes could just fork a process to do things they've declared that they won't do.
I wonder if this is related to the "capsicum needs you to rewrite programs" bit. I.e. the capsicum man page explicitly says
> Once set, the flag is inherited by future children processes, and may not be cleared.
And mentions that specific new APIs should be used in order to manage processes through capabilities.
Re: A subsystem to restrict programs into a “reduced feature operating model”
#50I can't see where in this patch forked children inherit the `ps_tame` from the parent process. I don't know this kernel at all but it seems like something like this should be in sys/kern/kern_fork.c pr->ps_tame = parent->ps_tame Otherwise tamed processes could just fork a process to do things they've declared that they won't do.
A tamed process cannot even call fork(2) unless the TAME_PROC flag is passed, in which case I'd assume the child process would then inherit a copy from the parent as part of a normal fork(2) operation. It can be later revoked by the child, but it may want to keep it for kill(2).
I'm `cvs get`ting as fast as I can to read the rest of sys_fork.c to sate my curiosity, but CVS incredibly slow. I'm spoiled by how git packs the repo.