From: mouss <mouss@netoyen.net>
To: Patrick McHardy <kaber@trash.net>
Cc: "Phil Oester" <kernel@linuxace.com>,
"Jozsef Kadlecsik" <kadlec@blackhole.kfki.hu>,
"Micha³ Miros³aw" <mirq-linux@rere.qmqm.pl>,
"Netfilter Developer Mailing List"
<netfilter-devel@vger.kernel.org>,
"Stephen Hemminger" <shemminger@vyatta.com>
Subject: Re: [RFC] Allowing non-root to get iptables info?
Date: Wed, 27 Feb 2008 18:48:18 +0100 [thread overview]
Message-ID: <47C5A262.9000106@netoyen.net> (raw)
In-Reply-To: <47C5830E.3070500@trash.net>
Patrick McHardy wrote:
> Phil Oester wrote:
>> On Wed, Feb 27, 2008 at 03:51:20PM +0100, Patrick McHardy wrote:
>>> Well, yes, the main question is whether this causes privacy issues.
>>> "Security by obscurity" is a pretty poor argument, does anyone have
>>> a well founded reason for not allowing users to see the rules and
>>> counters?
>>
>> I really don't think this is a good idea. We allow non-root users
>> on some of our firewalls, and I don't want them to see the ruleset.
>> Also, it helps miscreants to better pick their targets, if they
>> know in advance which ports are opened.
>
>
> They could also find out about this simply by probing ports ...
they could, but their IP may get blocked before that. if they know the
rules, they will avoid being trapped. of course, the attack requires
user collaboration, but why make it easier?
many people use "reactive" rules that blacklist an IP after N bad
requests. if an attacker knows how many requests during what period of
time he can do without being blacklisted, his task is easier. sure, a
botnet owner doesn't care as he can use a distributed attack, but that's
no reason to help silly kids.
or consider a case when a set of ports is forwarded to a set of hosts.
why would a user need to know? it's none of his business.
I would understand giving users information they need to do their job so
that they don't bother admins or spend too much time in useless
debugging. but this is different than giving access to _all_
informations to _all_ users. I said "security by obscurity", but it may
also be considered as "minimum privilege" (or one tool in a "defense in
depth" strategy)
>
>> If making this change, *please* consider making it configurable,
>> with the default being NO access.
>
>
> No, in that case I prefer to keep it restricted to root
> unconditionally. Using sudo to get the rules is no big
> deal I guess.
>
I agree. if it can be implemented in "user space", there is no reason to
"pollute" netfilter. one can even think of a program that gives specific
infos based on user/group rules.
next prev parent reply other threads:[~2008-02-27 17:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080225094951.5bd89c9c@extreme>
2008-02-27 11:52 ` [RFC] Allowing non-root to get iptables info? Patrick McHardy
2008-02-27 12:31 ` Michał Mirosław
2008-02-27 12:43 ` Patrick McHardy
2008-02-27 12:59 ` Jozsef Kadlecsik
2008-02-27 13:04 ` Patrick McHardy
2008-02-27 14:39 ` mouss
2008-02-27 14:51 ` Patrick McHardy
2008-02-27 15:31 ` Phil Oester
2008-02-27 15:34 ` Patrick McHardy
2008-02-27 15:43 ` Phil Oester
2008-02-27 16:34 ` Stephen Hemminger
2008-02-27 16:53 ` Patrick McHardy
2008-02-27 17:48 ` mouss [this message]
2008-02-27 16:51 ` Jan Engelhardt
2008-02-27 12:18 ` Patrick McHardy
2008-02-28 9:18 ` Harald Welte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47C5A262.9000106@netoyen.net \
--to=mouss@netoyen.net \
--cc=kaber@trash.net \
--cc=kadlec@blackhole.kfki.hu \
--cc=kernel@linuxace.com \
--cc=mirq-linux@rere.qmqm.pl \
--cc=netfilter-devel@vger.kernel.org \
--cc=shemminger@vyatta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.