Date: Fri, 8 Jul 2011 15:09:52 +0400 From: "Ilya Bakulin" <webmaster@kibab.com> To: "Matt" <sendtomatt@gmail.com> Cc: freebsd-hackers@freebsd.org, "Robert N. M. Watson" <robert.watson@cl.cam.ac.uk>, Jonathan Anderson <jonathan.anderson@cl.cam.ac.uk>, Ben Laurie <benl@google.com> Subject: Re: Capsicum project: Ideas needed Message-ID: <2c9d3cc8a0b85313f55f53ca573af81a.squirrel@zugang.kibab.com> In-Reply-To: <4E1685D8.403@gmail.com> References: <4E167C94.70300@kibab.com> <4E1685D8.403@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[CCing Ben, Robert and Jonathan as it's very important for me to receive their feedback about my thoughts] Let me focus on those application ideas that you've mentioned. All the following are my thoughts and this may be incorrect, in this case please correct me. > -any server software Yes, server software is a good candidate for bringing cap.mode in. Though this applies to servers that do not include in-process support for interpreters (ie Apache + mod_php), see later why. Such software as nginx, lighttpd is OK. Speaking about base system components, this list includes inetd daemons (but modification of inetd itself is NOT sufficient and ineffective, capability support implies modifying code of daemons) > -any interpreter (perl, python, etc)? Proper capsicumization of these things requires heavy code hacking, and probably won't be accepted by upstream anyway, until Capsicum becomes a standard not only for BSD world. Should hold on for now. > -any shell?... Processes that are started by the shell will inherit its capabilities. So this is undesirable IMHO. We should modify applications themselves. > minicom > wget > curl > links/lynx This is Ports software, we may try to modify it and even send patches to upstream, or maintain our local patches. I wanted to focus on base system components during GSoC, but it doesn't hurt to try to capsicumize these tools either. > netcat We have it in base system, will look at it. >From your first email: > How about sendmail and bind? I don't know how many people actually use sendmail in base system? Regarding bind -- it's a good idea, though bind already includes support for running in jail AFAIK. Thank you for your feedback! On Fri, July 8, 2011 8:21 am, Matt wrote: > 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 > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > !DSPAM:4e168c7810433083710550! > > > -- Regards, Ilya Bakulin http://kibab.com xmpp://kibab612@jabber.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2c9d3cc8a0b85313f55f53ca573af81a.squirrel>