linux-kernel - Re: RFC: disablenetwork facility. (v4)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 27 Dec 2009 20:49:17 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	pavel@....cz, viro@...IV.linux.org.uk
Cc:	michael@...top.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, linux-security-module@...r.kernel.org,
	andi@...stfloor.org, david@...g.hm, socketcan@...tkopp.net,
	alan@...rguk.ukuu.org.uk, herbert@...dor.apana.org.au,
	Valdis.Kletnieks@...edu, bdonlan@...il.com, zbr@...emap.net,
	cscott@...ott.net, jmorris@...ei.org, ebiederm@...ssion.com,
	bernie@...ewiz.org, mrs@...hic-beasts.com, randy.dunlap@...cle.com,
	xiyou.wangcong@...il.com, sam@...ack.fr, casey@...aufler-ca.com,
	serue@...ibm.com
Subject: Re: RFC: disablenetwork facility. (v4)

Pavel Machek wrote:
> Syscalls are very wrong granularity for security system. But easy to
> implement, see seccomp.

Quoting from http://en.wikipedia.org/wiki/Seccomp
> It allows a process to make a one-way transition into a "secure" state where
> it cannot make any system calls except exit(), read() and write() to
> already-open file descriptors. 

I think seccomp() is too much restricted to apply for general applications.
Most applications will need some other syscalls in addition to exit(), read()
and write(). Most applications cannot use seccomp().

What I want to do is similar to seccomp(), but allows userland process to
forbid some syscalls like execve(), mount(), chroot(), link(), unlink(),
socket(), bind(), listen() etc. selectively.

Al Viro wrote:
>> Application writers know better what syscalls the application will call than
>> application users.
> 
> Aren't you forgetting about libc?  Seriously, any interface along the
> lines of "pass a set of syscall numbers to kernel" is DOA:

We can determine what syscalls we need from application's code and libc's code,
can't we?
Otherwise, I think disablenetwork can't be used. If we simply forbid use of
sendmsg() because application's code doesn't use UDP sockets, DNS requests (UDP
port 53) by libc's code cannot be handled and applications will stop working.
We must know what syscalls we need to allow when we forbid some syscalls.

> 	* syscall numbers are architecture-dependent
> 	* there are socketcall-style multiplexors (sys_ipc, anyone?)
> 	* libc is free to substitute one for another
> 	* libc is free to do so in arch-specific manner
> 	* libc is free to do so in kernel-revision-specific manner
> 	* libc is free to do so in libc-revision-specific manner
> (... and does all of the above)
> 	* new syscalls get added
> 	* e.g. on sparc64 32bit task can issue 64bit syscalls

I don't mean to tell the kernel by "syscall numbers".
To be able to handle socketcall-style multiplexors, we will need a hook inside
each syscall functions.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/