From: ebiederm@xmission.com (Eric W. Biederman)
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
Philip Whineray <phil@firehol.org>,
Jan Engelhardt <jengelh@inai.de>,
netfilter-devel@vger.kernel.org
Subject: Re: [PATCH v2] Root in namespace owns x_tables /proc entries
Date: Mon, 16 Nov 2015 16:03:21 -0600 [thread overview]
Message-ID: <87vb91iouu.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20151116115659.GA16976@salvia> (Pablo Neira Ayuso's message of "Mon, 16 Nov 2015 12:56:59 +0100")
Pablo Neira Ayuso <pablo@netfilter.org> writes:
> On Sun, Nov 15, 2015 at 07:53:53PM +0100, Jozsef Kadlecsik wrote:
>> Hi Philip,
>>
>> On Sat, 14 Nov 2015, Philip Whineray wrote:
>>
>> > Since it's in danger of getting quite complicate, would one or more of
>> > the following be acceptable?
>> >
>> > - Choose permission in a module parameter
>> >
>> > - Allow setting with sysctl e.g. net.netfilter.conf.xtable_proc_perms
>> >
>> > - Match permissions of /proc/modules (grsec restricts these so we will
>> > gain the same policy).
>>
>> In my opinion either one is good and I'd pick the sysctl setting. That way
>> the permissions could be changed without reloading the module and
>> independently of the permissions of /proc/modules.
>
> I'd rather not to have a sysctl for this thing.
>
> I suspect it will not take long until someone else will follow up with
> a similar patch /proc/net/nf_conntrack.
>
> What is the plan of namespace people for unprivileged namespaces with
> non-world readable /proc entries?
If it makes sense to have them per namespace and allow manipulation by
the user namespace root, the plan is to make the files owned by the
root user in the user namespace that created the network namespace.
That preserves all of the existing logic.
If we don't trust the user namespace root to read/write the file we
probably want to just avoid creating the file altogether if
(net->user_ns != init_user_ns).
Eric
next prev parent reply other threads:[~2015-11-16 22:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-07 7:49 [PATCH] Expose x_tables /proc entries as 0444 not 0440 Philip Whineray
2015-11-11 16:50 ` Pablo Neira Ayuso
2015-11-11 18:25 ` Jozsef Kadlecsik
2015-11-11 18:40 ` Florian Westphal
2015-11-11 18:48 ` Jan Engelhardt
2015-11-11 19:35 ` Phil Whineray
2015-11-11 20:10 ` Jozsef Kadlecsik
2015-11-11 21:20 ` Phil Whineray
2015-11-14 9:12 ` [PATCH v2] Root in namespace owns x_tables /proc entries Philip Whineray
2015-11-15 18:53 ` Jozsef Kadlecsik
2015-11-16 11:56 ` Pablo Neira Ayuso
2015-11-16 12:57 ` Phil Whineray
2015-11-16 22:03 ` Eric W. Biederman [this message]
2015-11-16 21:56 ` Eric W. Biederman
2015-11-18 7:37 ` Phil Whineray
2015-11-18 9:13 ` Eric W. Biederman
2015-11-18 18:39 ` Phil Whineray
2015-11-22 11:35 ` [PATCH v3] Set /proc/net entries owner to root in namespace Philip Whineray
2015-11-25 12:55 ` Pablo Neira Ayuso
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=87vb91iouu.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=jengelh@inai.de \
--cc=kadlec@blackhole.kfki.hu \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=phil@firehol.org \
/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.