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

[Bodo Eggert <7eggert@gmx.de>]

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/