[lkml]   [2006]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] packet/socket owner match (fireflier) using skfilter
On Fri, 7 Apr 2006 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-04-07 22:09    [W:0.047 / U:17.692 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site