Re: why do we need seccomp?

On Thu, Jan 11, 2007 at 05:23:03PM +0200, Alex Fihman wrote:
> I've just thought, why do we need seccomp?
> 
> If client runs code in virtual machine, with read-only file systems 
> (CD-Rom),
> firewall blocking all traffic except for localhost and cpushare.com,
> what bad can be done to the PC?

selinux/apparmor could provide further security additionally to
running as normal user too.

The only problem with this approach (and the reason that seccomp
exists) is that the first kernel bug that allows raising privilege of
the local user to root (and most kernel out there have those bugs)
would potentially allow the attacker to overwrite /dev/mem and inject
his own storage drivers that would potentially access the
harddisk. This isn't easy, but it still sounds more feasible than to
achieve the same through seccomp. So if the cdrom wasn't booted under
virtualization it could damage the seller computer. You're right that
if the cd was run under virtualization, things would be more secure.
But to really be fully secure in terms of DDoS attacks, the firewall
that controls the outgoing connections should live in the
virtualization layer (or anyway not in the kernel of the CPUShareLiveCD).

The other advantage of seccomp is that it doesn't require
virtualization, but you can run it on a normal linux system as long as
the kernel has been compiled with CONFIG_SECCOMP=y.

SECCOMP is a tradeoff and the basic computing model to give a peace of
mind to the sellers, but for sure it won't be enough in the long
term. I totally understand the need of running legacy applications
unmodified (and to compute bytecodes other than x86/ppc). This will
have to be addressed one way or another.

> seccomp is too restrictive, IMHO. Having Java and mysql installed and
> allowing C++, many existing projects will be easily ported to CPUShare.

The other problem with running applications unmodified, is the TCP
stack and the reliability of the remote nodes. In a normal cluster,
all nodes would have their own ip address and they wouldn't disappear
at any time from the network. With CPUShare the remote hosts don't
have an ip address (the sellers are behind their NAT and their
firewalls) and they can disconnect at any time. Not all cluster
applications are fault tolerant and they all need normal ip
addresses. The lack of ip part, can be solved by running an openvpn
server on the buyer node, and the openvpn client on the seller
nodes. So at least the ip part can be solved. There would be still the
issue that not all apps would survive one of the remote nodes
disappearing without warning. The only thing that could help would be
to run the same image in lock step on two systems, but that would be
very complicated.

Yet another approach could be to implement transparent process
migration through CPUShare at the kernel level. Then it'll be the
buyer linux kernel that would take care of migrating certain tasks
remotely through CPUShare (that way you could even migrate gzip during
a backup) but this would also require huge changes in both the buyer
and seller kernels.

> Let's make a vote, who will allow running non-seccomp client?
> Also, lets vote, what is the allowed size of the client image?

Nobody voted yet. I'm curious. I know Ed would probably be running the
non-seccomp version too, he was suggesting a raw mode w/o seccomp
about one year ago (so he could run python in the seller computer,
python doesn't work under seccomp). Both Ed and you are watching
CPUShare from the buyer point of view, I'd be interesting to know the
seller point of view too.

While I welcome discussions on the way to go for the future, before
working any non-seccomp livecd I intend to reach a working status with
djohn ported to seccomp and to have the invoicing subsystem functional
and enabled.
-- 
cpushare-discuss@cpushare.com mailing list - http://www.cpushare.com/
To unsubscribe, send mail to cpushare-discuss-unsubscribe_X_at_X_cpushare.com