Capsicum project: Ideas needed

[Ilya Bakulin]

[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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>
> !DSPAM:4e168c7810433083710550!
>
>
>


-- 
Regards,
Ilya Bakulin
http://kibab.com
xmpp://kibab612@jabber.ru