Re: secure computing for 2.6.7

[Andrea Arcangeli]

On Sun, Aug 01, 2004 at 01:01:10PM +0100, chris@xxxxxxxxxxxxxxxx wrote:
> Hi Andrea,
> 
> Do you have plans to generalize seccomp into somelike like a "syscall
> firewall"? This _would_ be useful to many apps, and provide good security
> benefits - for example, vsftpd does not need most of the previously-buggy
> syscalls such as sysctl(), mremap() and execve(). But it does need more
> than just read(), write() and exit()!

Seems like a few people is interested in what you suggest above. it'd be
very trivial to add a seccomp-mode = 2 that adds more syscalls like the
socket syscalls like accept/sendfile/send/recv and also the open syscall
(which means you want to use chroot still).  In the code you can see I
wrote it so that more modes can be added freely. I mean it has some
flexibility already.  vsftpd could enable the seccomp mode 2 on itself
after it has initialized.

(this is only a trivial patch example of the extension) 

--- security-sequence/kernel/seccomp.c.~1~	2004-08-01 16:10:46.970806680 +0200
+++ security-sequence/kernel/seccomp.c	2004-08-01 16:17:17.537431528 +0200
@@ -30,12 +30,31 @@ static int mode1_syscalls[] = {
 #endif
 };
 
+/*
+ * Secure computing mode 2 is for network daemons.
+ */
+static int mode2_syscalls[] = {
+#ifdef __NR_sigreturn
+	__NR_rt_sigreturn,
+#endif
+	__NR_open, __NR_sendfile, __NR_sendfile64, __NR_close,
+	__NR_poll, __NR_fork, __NR_wait4, __NR_socketcall, __NR_getdents,
+	__NR_mmap2, __NR_munmap,
+};
+
 void secure_computing(int this_syscall)
 {
 	int mode = current->seccomp_mode;
 	int * syscall;
 
 	switch (mode) {
+	case 2:
+		for (syscall = mode2_syscalls;
+		     syscall < mode2_syscalls + sizeof(mode2_syscalls)/sizeof(int);
+		     syscall++)
+			if (*syscall == this_syscall)
+				return;
+		/* mode 2 extends mode 1: fallthrough */
 	case 1:
 		for (syscall = mode1_syscalls;
 		     syscall < mode1_syscalls + sizeof(mode1_syscalls)/sizeof(int);


the above might be enough to make a network daemon work, but it probably
would still need some userspace modification to ensure it fits, and you
may have to add some reasonably safe syscall that I might have forgotten
in the example.

plus you'd still need a chroot to limit the scope of the "open" syscall.

to make threading work futex and clone and some other is going to be
needed by glibc.

After that it would be _very_ secure thanks to the seccomp mode 2.
Especially the fact they've no way to exec is quite nice since they
always try to find the /bin/sh string somewhere to make the thing work.

I can imagine some people may want a true firewall configurable via
userspace, so that they can filter the syscall parameters too and they
can customize it as they need. the seccomp patch conceptually fits that
need just fine too but you've to write the code and extended it for that ;).
That would be seccomp mode >=3.

I'm posting these emails so much in advance just to raise discussion of
what people would like to see implemented so that it benefits everybody
so any extension is welcome.  OTOH while I will certainly help auditing
any extension of the seccomp mode I'm probably not going to have spare
resources to spend in writing that fully featured syscalltables firewall
mode >=3 that some people would like to see. I hope somebody else will
volounteer for that if there's an agreement that's the way to go ;). The
basic seccomp infrastructure/entry-point is there to build it. The
syscall parameters can be trivially passed down by adding a few more
params to the secure_computing function.

The important thing is to verify the API is extendible and I think it
is. The way this could work is to merge the patch as-is and to later add
a seccomp-mode == 2 for relaxed network daemon usage, and to later make
all seccomp modes from 3 to max-int to be configurable with a firewall
ala iptables when somebody volounteers to implement that. I really like
keeping mode 1 static and dumb (that is a feature), this way I'll never
risk somebody to mess the syscalltables firewall and to create an hole
in its own machine, and most important I would never need to depend on
the code in "case 3:" to be safe, since that is going to be a lot more
complicated and in turn less secure than the "case 1:" code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/