| Message ID | 20151107074939.GA4003@compaq.slightly-cracked.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Pablo Neira |
| Headers | show |
On Sat, Nov 07, 2015 at 07:49:39AM +0000, Philip Whineray wrote: > Reading these files is impossible in an unprivileged user namespace, > interfering with various firewall tools. For instance, iptables-save > relies on reading /proc/net/ip_tables_names to dump only loaded tables. > > Hiding the contents from non-root users does not achieve anything > practical. Possible values are well-known and the specifics can > be inferred from a list of loaded modules on most systems. > > Signed-off-by: Philip Whineray <phil@firehol.org> > --- > An alternate might be to change the ownership of the files within the > namespace when it is created: > > https://lists.linuxcontainers.org/pipermail/lxc-users/2014-November/008110.html > > I do not see that there is much advantage to this, it just ties the > ability to read the files to the ability to create an unprivileged > namespace. So I understood this correctly, this approach would set the ownership of the /proc entry to the corresponding root uid mapping from the unpriviledged namespace, right? If so, I would prefer that approach. This is partially leaking the filtering policy to non-root users as it contains what modules are being used, so you can at least infer how complex your ruleset is. And I guess it will not be long time until someone else will follow up with a similar patch later on to expose the content of /proc/net/nf_conntrack to get this working on unpriviledged namespaces too. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 11 Nov 2015, Pablo Neira Ayuso wrote: > On Sat, Nov 07, 2015 at 07:49:39AM +0000, Philip Whineray wrote: > > Reading these files is impossible in an unprivileged user namespace, > > interfering with various firewall tools. For instance, iptables-save > > relies on reading /proc/net/ip_tables_names to dump only loaded tables. > > > > Hiding the contents from non-root users does not achieve anything > > practical. Possible values are well-known and the specifics can > > be inferred from a list of loaded modules on most systems. > > > > Signed-off-by: Philip Whineray <phil@firehol.org> > > --- > > An alternate might be to change the ownership of the files within the > > namespace when it is created: > > > > https://lists.linuxcontainers.org/pipermail/lxc-users/2014-November/008110.html > > > > I do not see that there is much advantage to this, it just ties the > > ability to read the files to the ability to create an unprivileged > > namespace. > > So I understood this correctly, this approach would set the ownership > of the /proc entry to the corresponding root uid mapping from the > unpriviledged namespace, right? If so, I would prefer that approach. > > This is partially leaking the filtering policy to non-root users as it > contains what modules are being used, so you can at least infer how > complex your ruleset is. > > And I guess it will not be long time until someone else will follow up > with a similar patch later on to expose the content of > /proc/net/nf_conntrack to get this working on unpriviledged namespaces > too. Can't it be worked out by using CAP_NET_ADMIN? I don't really like the idea to expose the files to non root users or users with not sufficient capabilities. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Pablo Neira Ayuso <pablo@netfilter.org> wrote: > > Hiding the contents from non-root users does not achieve anything > > practical. Possible values are well-known and the specifics can > > be inferred from a list of loaded modules on most systems. I agree, thus Acked-by: Florian Westphal <fw@strlen.de> -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 2015-11-11 19:40, Florian Westphal wrote: >Pablo Neira Ayuso <pablo@netfilter.org> wrote: >> > Hiding the contents from non-root users does not achieve anything >> > practical. Possible values are well-known and the specifics can >> > be inferred from a list of loaded modules on most systems. Conversely, an administrator could just load all modules to give a false impression. Since the adversary can in turn expect it, he knows as little as before. In particular, containerized environments will have it such that many modules are loaded, but each container still has their own ruleset. So yeah, hiding the contents is not going to achieve anything - nor is showing. (I am concurring here with the other respondents.) -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 11, 2015 at 07:48:11PM +0100, Jan Engelhardt wrote: > On Wednesday 2015-11-11 19:40, Florian Westphal wrote: > >Pablo Neira Ayuso <pablo@netfilter.org> wrote: > >> > Hiding the contents from non-root users does not achieve anything > >> > practical. Possible values are well-known and the specifics can > >> > be inferred from a list of loaded modules on most systems. > > Conversely, an administrator could just load all modules to give a false > impression. Since the adversary can in turn expect it, he knows as > little as before. In particular, containerized environments will have it > such that many modules are loaded, but each container still has their > own ruleset. > So yeah, hiding the contents is not going to achieve anything - nor is > showing. (I am concurring here with the other respondents.) Sorry - I've gotten confused about who thinks what exactly. I hope the below isn't wasting everyone's time. Unhiding /proc/ip_tables_names content achieves something specific: it is used by iptables-save to determine what it should write out (in the absence of a specific table being asked for, which I believe is the norm). I currently have a workaround using a horrific series of bind mounts which substitutes in a normal file with the values iptables-save expects. Two alternates on the table are: - change ownership of the file in the namespace (wherein a user runs "unshare -U -r -n cat /proc/net/ip_tables_names" to do the same as "cat /proc/net/ip_tables_names" with 0444 perms, so not adding much unless unprivileged namespaces are disabled. - try to do something with capabilities (I'd need to research this) Given /proc/modules is 0444 and the observation that loaded != used I don't think any significant information is leaked by the patch. I don't mind having a stab at an alternate implementation but is it worth it? -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 11 Nov 2015, Phil Whineray wrote: > On Wed, Nov 11, 2015 at 07:48:11PM +0100, Jan Engelhardt wrote: > > On Wednesday 2015-11-11 19:40, Florian Westphal wrote: > > >Pablo Neira Ayuso <pablo@netfilter.org> wrote: > > >> > Hiding the contents from non-root users does not achieve anything > > >> > practical. Possible values are well-known and the specifics can > > >> > be inferred from a list of loaded modules on most systems. > > > > Conversely, an administrator could just load all modules to give a false > > impression. Since the adversary can in turn expect it, he knows as > > little as before. In particular, containerized environments will have it > > such that many modules are loaded, but each container still has their > > own ruleset. > > So yeah, hiding the contents is not going to achieve anything - nor is > > showing. (I am concurring here with the other respondents.) > > Sorry - I've gotten confused about who thinks what exactly. I hope > the below isn't wasting everyone's time. My opinion is that the files should not be exposed. Whenever it does not clash something vital and cannot be resolved I run kernels with grsec, where normal user cannot list the loaded in kernel modules. By exposing these files, some part of that data would then be leaked out. > Unhiding /proc/ip_tables_names content achieves something specific: it > is used by iptables-save to determine what it should write out (in > the absence of a specific table being asked for, which I believe is > the norm). > > I currently have a workaround using a horrific series of bind mounts > which substitutes in a normal file with the values iptables-save expects. > > Two alternates on the table are: > > - change ownership of the file in the namespace (wherein a user runs > "unshare -U -r -n cat /proc/net/ip_tables_names" to do the same as > "cat /proc/net/ip_tables_names" with 0444 perms, so not adding much > unless unprivileged namespaces are disabled. I don't quite understand this: if the ownership of the files are changed, then why do you need to change the access right to 0444? > - try to do something with capabilities (I'd need to research this) > > Given /proc/modules is 0444 and the observation that loaded != used > I don't think any significant information is leaked by the patch. I > don't mind having a stab at an alternate implementation but is it worth > it? Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 11, 2015 at 09:10:13PM +0100, Jozsef Kadlecsik wrote: > On Wed, 11 Nov 2015, Phil Whineray wrote: > > > On Wed, Nov 11, 2015 at 07:48:11PM +0100, Jan Engelhardt wrote: > > > On Wednesday 2015-11-11 19:40, Florian Westphal wrote: > > > >Pablo Neira Ayuso <pablo@netfilter.org> wrote: > > > >> > Hiding the contents from non-root users does not achieve anything > > > >> > practical. Possible values are well-known and the specifics can > > > >> > be inferred from a list of loaded modules on most systems. > > > > > > Conversely, an administrator could just load all modules to give a false > > > impression. Since the adversary can in turn expect it, he knows as > > > little as before. In particular, containerized environments will have it > > > such that many modules are loaded, but each container still has their > > > own ruleset. > > > So yeah, hiding the contents is not going to achieve anything - nor is > > > showing. (I am concurring here with the other respondents.) > > > > Sorry - I've gotten confused about who thinks what exactly. I hope > > the below isn't wasting everyone's time. > > My opinion is that the files should not be exposed. Whenever it does not > clash something vital and cannot be resolved I run kernels with grsec, > where normal user cannot list the loaded in kernel modules. By exposing > these files, some part of that data would then be leaked out. > > > Unhiding /proc/ip_tables_names content achieves something specific: it > > is used by iptables-save to determine what it should write out (in > > the absence of a specific table being asked for, which I believe is > > the norm). > > > > I currently have a workaround using a horrific series of bind mounts > > which substitutes in a normal file with the values iptables-save expects. > > > > Two alternates on the table are: > > > > - change ownership of the file in the namespace (wherein a user runs > > "unshare -U -r -n cat /proc/net/ip_tables_names" to do the same as > > "cat /proc/net/ip_tables_names" with 0444 perms, so not adding much > > unless unprivileged namespaces are disabled. > > I don't quite understand this: if the ownership of the files are changed, > then why do you need to change the access right to 0444? You're right, I don't. I was just noting point that if unprivileged namespaces are available, either suffices for a regular user to see the contents. Cheers Phil -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c index 9b42b5e..c05adde 100644 --- a/net/netfilter/x_tables.c +++ b/net/netfilter/x_tables.c @@ -1236,21 +1236,21 @@ int xt_proto_init(struct net *net, u_int8_t af) #ifdef CONFIG_PROC_FS strlcpy(buf, xt_prefix[af], sizeof(buf)); strlcat(buf, FORMAT_TABLES, sizeof(buf)); - proc = proc_create_data(buf, 0440, net->proc_net, &xt_table_ops, + proc = proc_create_data(buf, 0444, net->proc_net, &xt_table_ops, (void *)(unsigned long)af); if (!proc) goto out; strlcpy(buf, xt_prefix[af], sizeof(buf)); strlcat(buf, FORMAT_MATCHES, sizeof(buf)); - proc = proc_create_data(buf, 0440, net->proc_net, &xt_match_ops, + proc = proc_create_data(buf, 0444, net->proc_net, &xt_match_ops, (void *)(unsigned long)af); if (!proc) goto out_remove_tables; strlcpy(buf, xt_prefix[af], sizeof(buf)); strlcat(buf, FORMAT_TARGETS, sizeof(buf)); - proc = proc_create_data(buf, 0440, net->proc_net, &xt_target_ops, + proc = proc_create_data(buf, 0444, net->proc_net, &xt_target_ops, (void *)(unsigned long)af); if (!proc) goto out_remove_matches;
Reading these files is impossible in an unprivileged user namespace, interfering with various firewall tools. For instance, iptables-save relies on reading /proc/net/ip_tables_names to dump only loaded tables. Hiding the contents from non-root users does not achieve anything practical. Possible values are well-known and the specifics can be inferred from a list of loaded modules on most systems. Signed-off-by: Philip Whineray <phil@firehol.org> --- An alternate might be to change the ownership of the files within the namespace when it is created: https://lists.linuxcontainers.org/pipermail/lxc-users/2014-November/008110.html I do not see that there is much advantage to this, it just ties the ability to read the files to the ability to create an unprivileged namespace. net/netfilter/x_tables.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)