Re: [RFC] packet/socket owner match (fireflier) using skfilter

From: edwin
Date: Sat Apr 08 2006 - 03:51:34 EST


On Fri, Apr 07, 2006 at 10:06:45PM +0200, Bodo Eggert wrote:
> On Fri, 7 Apr 2006 edwin@xxxxxxxxx wrote:
>
> If apache is running a CGI script, it must pass the socket (bound to
> remote:port,local:80, to the CGI at fd 2*. If your firewall is blocking
> this, your CGI scripts will stop working.
Hmm, an exception could be made for programs like apache.
The user would then create a rule that says that apache is allowed to pass on
file descriptors.
Or a rule could be created for the userspace part of fireflier that would auto-add the cgi-scripts
to apache's group sid. Which IMHO would be the best, because the user will still have control on
what programs have access to the network. He can see that list at any time, and modify it, if not correct.
If we would simply allow file descriptors to be passed on, he wouldn't have that control.
(none of this is implemented yet)
> > running a program via NFS, and giving access for it to the network? why
> > would I want that?
>
> Why not? E.g. you could set up a farm of redundand apache servers.
Ok, so the userspace part of fireflier will have to deal with nfs mounts as a special case.
It should store the rules in "server,path,executable hash" format, and do the inode lookup on startup,
or when the first packet arrives.
> > Aren't inodes stored on the disk?
>
> At least Mostly, but is this a requirement?
Currently it is, until we implement path+hash rules for nfs mounts,etc.
What devices can I safely assume that the inodes won't change over boots/mounts?

Cheers,
Edwin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/