how ensure the seccomp policies is effective？ about sandboxed-api HOT 8 CLOSED

sorry that my point is irrelevant to this issue. but wanted to share my views.
thanks

from sandboxed-api.

2. The `AllowSystemMalloc` interface, it's implemented very complexed，not only limit the system call ` but also limit the args.  why?  What references do you have? or have some evidence ？`

even i think the same.
as far as i know this project is tightly coupled to google's protocol buffers. AllowRead, Allowsocketrecive and lot of other calls should be add must and should.
which seems to be bad.
having it tied to google's protocal buffer is bad. there are scenarios where protocalbuffers are not accepted, we always have to write wrappers and allow those syscalls.
IMO.
@cblichmann any ideas?

from sandboxed-api.

Hi,

1. In the ideal case you have a look at what syscalls the sandboxee actually uses and whitelist them individually, potentially by checking for the contents of the arguments.
   In order to make it less cumbersome to write policies, we created some helper functions that will whitelist commonly used syscalls which brings us to
2. AllowSystemMalloc - I don't know if I have a different codebase, but it allows munmap, mremap(MREMAP_MAYMOVE) and mmap with specific parameters. Those are syscalls that are used by the system malloc on my machine and it seems to be the same for others. Asking for references or evidence is.. difficult as those allocators change over time.

Can you elaborate on what this has to do with protobufs? Sapi has support for protobufs, but there is no need to use them.

from sandboxed-api.

Another comment on creating a policy, you can use the "sandbox2_danger_danger_permit_all_and_log" flag to do some 'strace like' logging of all syscalls that are used by the sandboxee. This doesn't necessarily mean that it is minimal or effective afterwards. You might be able to return errors on some syscalls without breaking the program (libc has some fallbacks when syscalls are not available), also some syscalls should potentially not be enabled at all, e.g. ptrace.

from sandboxed-api.

now i get it. execution is launching new process and transfer data with protocol buffers.
for better explanation refer here

from sandboxed-api.

Another comment on creating a policy, you can use the "sandbox2_danger_danger_permit_all_and_log" flag to do some 'strace like' logging of all syscalls that are used by the sandboxee. This doesn't necessarily mean that it is minimal or effective afterwards. You might be able to return errors on some syscalls without breaking the program (libc has some fallbacks when syscalls are not available), also some syscalls should potentially not be enabled at all, e.g. ptrace.

Thank you! You mean that i should choose what policies after i know the execute bin's all system calls. But that very paradoxical， if i knew the all system calls， i know if it is safe or not. so i do not need the sandbox protection.
I think establishing a security policy is very difficult. Maybe it's a balance between functionality and security。 if limit too much， that affects functionality, and if you limit too few, that's a security risk。

from sandboxed-api.

Ah, you have a different usecase then. I was under the assumption that you'd like to sandbox a binary that might get exploited, not a unknown binary that should not mess with your system.

Can you maybe give me some more details here? Is it one unknown application? Do you want a 'generic' policy? What exactly are your goals? You can always run the binary in a VM with this flag, get the list of syscalls and apply it outside of the VM.

from sandboxed-api.

Closing this question as @fluxchief has answered it.

from sandboxed-api.