Messages in this thread | | | Date | Fri, 7 Apr 2006 22:06:45 +0200 (CEST) | From | Bodo Eggert <> | Subject | Re: [RFC] packet/socket owner match (fireflier) using skfilter |
| |
On Fri, 7 Apr 2006 edwin@gurde.com wrote:
> > I'd deliberately allow access to these sockets if it's passed to other > > applications since it's the intended behaviour.
> It might be intended behaviour, or it might be a file descriptor leak. > If I have a rule in iptables saying to allow only apache (just an example) > access to port 80, I don't want any other program to have access to it. > If apache might leak a file descriptor (it doesn't, just an example), and > give access to other programs, the firewall would restrict those programs. > If I would implicitly trust them, then fireflier rules wouldn't be any > better, than just creating rules to allow any program to listen on port > 80.
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.
* unless it intends to proxy the connection
> > (BTW: Your approach isn't > > going to be 100 % reliable, since it will allow other processes to > > illegaly > > receive data if the socket is transfered after filtering, isn't it?) > filtering is done on each packet, how could the socket be transfered > between the time the packet is filtered, and the time it is received by > the program? > A socket transfer can be done via execve, or IPC, both covered (I hope) by > the fireflier lsm. > > > > Downside of both approaches: > > You'll have to guarantee stable dev:inode pairs. > This could be ensured from userspace, if it becomes an issue. > > NFS?
> 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.
> Anyway, if somebody wants that, we could determine the inode of the > program on nfs mount time. We could store the path+hash of the program to > be sure it is the same program.
> >umount/mount? > Aren't inodes stored on the disk?
At least Mostly, but is this a requirement? -- Fun things to slip into your budget True and it was approved: 128 MBytes of VIRTUAL memory. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |