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

[edwin@gurde.com]

> I had a very simple idea for doing something like this:
Your idea is interesting. Unfortunately it is not directly applicable, and
is more a "hack", than a solution.
>
> Assign a special semantic to GID $n: Being in group $n allows you to
> listen
> on port $n-$offset. $offset == -1 disables this feature (default).
Modifying gids is not a good idea, the sysadmin might need it for other
purposes.
> If I'd want it to work with iptables, I'd extend the socket struct to
> contain
> the device:inode of the corresponding application (not changing it on
> exec)
and that would require recompiling the kernel
> and stat() the allowed applications on rule setups.
>
> 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.

> (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?
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?
>  Workaround: suid helper setting/deleting the allowed-rule?
No need for suid though, fireflier-server runs as root.
>

Cheers,
Edwin
-
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/