On Mon, Oct 27, 2008 at 10:27:20PM +0100, Lennart Poettering wrote:
On Mon, 27.10.08 23:08, Axel Thimm (Axel.Thimm@ATrpms.net) wrote:
On Mon, Oct 27, 2008 at 09:55:56PM +0100, Lennart Poettering wrote:
But dynamical ports are not new to iptables, lots of protocols, be that rpc, h323 or even p-o-d passive ftp need them and conntrack/pom rectify the `static firewall' view.
But all those protocols start the connection with a well known port and then hand things off to a dynamic port. If you use truely random ports than iptables needs to sense what kind of protocol something is based on the packet contents. Which security-wise is a joke, and hence the whole idea makes no sense.
And there are services that use truely random ports? E.g. w/o any handshaking or negotiation about these ports by well-defined processes? Why do we have mDNS/DNS-SD/SSDP for?
So you are suggesting that a firewall should automatically whitelist all ports that are announced via mDNS on the network? Wow. That it is certainly one hell of a good idea. Oh my.
No, just like the people using active FTP mode never implicitely suggested this either. But if *you* are annoyed for your rhythmbox not automatically sharing its files you could use this mechanism.
Are you sure you really understand what "security" means?
I do, but it's funny to be asked by the person that suggests whitelisting everything, e.g. removing the firewall completely.
"Security" certainly doesn't mean whitelisting everything that someone likes to announce on the network via mDNS/DNS-SD.
It's nice you realize this. But you suggested using listen(2) instead for this purpose in previous mails ...
Anyway it's glad to see a change in mind.
I haven't followed up the latest netfilter developments, but I know there is even a userspace lib for registering such connections. Maybe RB/mDNS and friends just need a pom `plugin'.
The Linux kernel already has an API for that. It's called listen().
Cool, so any local non-priviledged process could open up holes in the firewall above ports 1024 as it pleases w/o the user even noticing.
Yes. Absolutely. If he wants to use an app he will circumvent the fw anyway. And hence the fw is pointless and it would be far smoother to allow this kind of operation without nagging.
So will the superuser do with selinux and any other security feature. Is the consequence to not even ship it or enable it? Not really.
Why not remove password protection from accounts while we are at it? ;)
Hmm, so you did have a clown for breakfast, didn't you?
You seem to divert into colorful metaphores once your arguments are smoked up. If I were to answer in the same style, I'd notice that you are still writing emails, so, no, I did not eat you ;)