Date: Thu, 07 Jul 2011 21:21:44 -0700 From: Matt <sendtomatt@gmail.com> To: freebsd-hackers@freebsd.org Cc: Ben Laurie <benl@google.com> Subject: Re: Capsicum project: Ideas needed Message-ID: <4E1685D8.403@gmail.com> In-Reply-To: <4E167C94.70300@kibab.com> References: <4E167C94.70300@kibab.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/07/11 20:42, Ilya Bakulin wrote: > Hi hackers, > As a part of ongoing effort to enhance usage of Capsicum in FreeBSD base > system, I want to ask you, which applications in the base system should > receive sandboxing support. > So far, the following applications were sandboxed during initial > Capsicum research project: > sshd: critical system service run by root; > gzip: utility that operates with potentially buggy compression code > tcpdump: contains complex packet-parsing code, run by root; > I have added sandboxing to syslogd, because this is also a critical > system service run by root. > I'm also going to add sandboxing to xz (compression algorithms) and ntpd > (critical system service run by root). > > The question is: which applications should also be processed? I think > that the most wanted candidates are SUID programs and/or popular network > daemons. > But looking at gzip example I also think about text-processing tools in > general. > > At the moment I prefer not to focus on applications that are used only > on desktop system -- primary usage of FreeBSD is ultra-reliable serving > platform, although iXSystems guys may correct me :-) > I'm not too familiar with the operation of capsicum, but in general anything with untrusted (including in many cases user) input can be worth sandboxing, especially in a server environment. Obviously server processes themselves are often worth restricting to things like jails or vms etc., so sandboxing could be an alternative. I can also see cases where interpreters, database server software, and file viewers/editors could be sandboxed to prevent exploits from "running away" with the system via the exploited process. Especially in server environment, 'sudo less /var/log/<evillogwithlessexploit>' and kablooey. Admins may have to run "user" software, or non suid, executables which nonetheless receive the admin's elevated permissions. Call them usid, user set id, I suppose. Not the best, but it happens, especially when things need to work an hour ago. A few ideas along those lines: -any server software -any interpreter (perl, python, etc)? -any shell?... minicom wget curl netcat links/lynx Can it be made a switch on sudo? sudo --sandbox=someprofile,option tcpdump -tti pflog0 Hopefully I'm not missing the boat and these ideas are applicable :) Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E1685D8.403>