Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux sandbox review #2

Open
kmcallister opened this issue Mar 5, 2015 · 20 comments
Open

Linux sandbox review #2

kmcallister opened this issue Mar 5, 2015 · 20 comments

Comments

@kmcallister
Copy link

No description provided.

@kmcallister
Copy link
Author

seccomp.rs:

#[cfg(target_arch="x86")]
const ARCH_NR: u32 = AUDIT_ARCH_X86;
#[cfg(target_arch="x86_64")]
const ARCH_NR: u32 = AUDIT_ARCH_X86_64;
#[cfg(target_arch="arm")]
const ARCH_NR: u32 = AUDIT_ARCH_ARM;
// ...
const __AUDIT_ARCH_64BIT: u32 = 0x8000_0000;
const __AUDIT_ARCH_LE: u32 = 0x4000_0000;
const AUDIT_ARCH_X86_64: u32 = EM_X86_64 | __AUDIT_ARCH_64BIT | __AUDIT_ARCH_LE;

Can you explain what these are for?

@kmcallister
Copy link
Author

This needs a comment:

/// Syscalls that are always allowed.
static ALLOWED_SYSCALLS: [u32; 22] = [
    ...
    NR_unknown_318,
}

@kmcallister
Copy link
Author

I'd like to whitelist advice values for madvise. Linux has a habit of adding weird features to madvise that are not really "memory advice".

@kmcallister
Copy link
Author

A quasiquote macro for BPF programs would be pretty sweet ^_^

@kmcallister
Copy link
Author

Can we whitelist socket ops by address family, too? You can do a lot of weird stuff with sockets — DBus, kernel crypto APIs, and even more obscure things where kernel 0days are likely to hide.

@kmcallister
Copy link
Author

I'd also like a test that tries every forbidden syscall number, to guard against (some) bugs in the BPF code.

@kmcallister
Copy link
Author

Is there a BPF disassembler we could use to look at some of the generated programs?

@kmcallister
Copy link
Author

Can we whitelist socket ops by address family, too?

nm, I see you're doing that already:

// Only allow Unix, IPv4, IPv6, and netlink route sockets to be created.

Why do we need to allow route sockets? Are they used by unprivileged processes to query the routing table?

@kmcallister
Copy link
Author

let src = CString::from_slice(b"tmpfs");
...
let tmpfs = CString::from_slice(b"tmpfs");

These could be the same variable, right?

@kmcallister
Copy link
Author

mount(src.as_ptr(), dest.as_ptr(), tmpfs.as_ptr(), MS_NOATIME, ptr::null())

How about MS_NOATIME | MS_NODEV | MS_NOEXEC | MS_NOSUID just for good measure? Some of those could cause problems, though.

@kmcallister
Copy link
Author

Is there code to close unwanted file descriptors before entering the sandbox? It would be good to iterate over all fd's in case some random library has opened something.

@kmcallister
Copy link
Author

Everything else in gaol/platform/linux looks good to me.

@kmcallister
Copy link
Author

Oh, do we want to set a umask?

@kmcallister
Copy link
Author

prctl(PR_SET_DUMPABLE, 0) seems like another miscellaneous safeguard that could be slightly useful.

@l0kod
Copy link

l0kod commented Mar 6, 2015

cc rust-lang/rust#12148

@pcwalton
Copy link
Contributor

pcwalton commented Mar 9, 2015

@kmcallister Yeah, netlink route is used for stuff like gethostbyname, unfortunately.

@pcwalton
Copy link
Contributor

pcwalton commented Mar 9, 2015

@kmcallister I don't actually know why we have to validate architectures (since it seems obvious that you can only call syscalls on the same architecture you're on?) but Chromium does it so I did it too.

@pcwalton
Copy link
Contributor

pcwalton commented Mar 9, 2015

@kmcallister It's actually important on some OS's to keep file descriptors open when entering the sandbox. Most notably, Chromium does this on Windows, because some OS APIs (e.g. fonts, IIRC) have to "warm up" by opening some handles, but which handles those are vary from OS release to OS release, so you can't really whitelist them portably.

@pcwalton
Copy link
Contributor

pcwalton commented Mar 9, 2015

@kmcallister Comments addressed. Here's a disassembly of the BPF for a restrictive filter: https://gist.github.com/anonymous/6988b4b8456678cb58f6

@heyimgay
Copy link

heyimgay commented Dec 2, 2015

Firejail could be a source of inspiration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants