linux-kernel - Re: [PATCH, RESEND] procfs: silence lockdep warning about read vs. exec seq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 5 Aug 2014 11:46:14 +0300
From:	"Kirill A. Shutemov" <kirill@...temov.name>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"David S. Miller" <davem@...emloft.net>
Cc:	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	David Howells <dhowells@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Sasha Levin <levinsasha928@...il.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Oleg Nesterov <oleg@...hat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH, RESEND] procfs: silence lockdep warning about read vs.
 exec seq_file

On Mon, Aug 04, 2014 at 08:42:11PM -0700, Eric W. Biederman wrote:
> "Kirill A. Shutemov" <kirill@...temov.name> writes:
> 
> > From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
> >
> > Testcase:
> >
> >   cat /proc/self/maps >/dev/null
> >   chmod +x /proc/self/net/packet
> >   exec /proc/self/net/packet
> >
> > It triggers lockdep warning:
> 
> > I don't know why we allow "chmod +x" on some proc files, notably net-related.
> > Is it a bug?
> 
> It looks like we simply did not remove the ability to make those files
> executable when we realized executable proc files could be a problem.
> 
> I expect that part of proc could use an audit where someone figures out
> what makes sense.  It does appear that chmod XXX /proc/generic_file
> is explicitly supported.  So we would have to be delicate with any
> changes in that area to avoid creating userspace regressions.

I can't imagine valid use-case, taking into account that changing access
rights for one PID changes it for every PID. It's potential security hole
if user is not aware about this (I wasn't until recently).

List of files under /proc/PID/ which doesn't fail chmod to its current
access rights -- chmod "$(stat --format="%a" "$file")" "$file":

net/anycast6
net/arp
net/connector
net/dev
net/dev_mcast
net/dev_snmp6/eth0
net/dev_snmp6/lo
net/fib_trie
net/fib_triestat
net/icmp
net/icmp6
net/if_inet6
net/igmp
net/igmp6
net/ip6_flowlabel
net/ip6_tables_matches
net/ip6_tables_names
net/ip6_tables_targets
net/ip_mr_cache
net/ip_mr_vif
net/ip_tables_matches
net/ip_tables_names
net/ip_tables_targets
net/ipv6_route
net/mcfilter
net/mcfilter6
net/netfilter/nf_log
net/netlink
net/netstat
net/nf_conntrack
net/nf_conntrack_expect
net/packet
net/pnp
net/protocols
net/psched
net/ptype
net/raw
net/raw6
net/route
net/rt6_stats
net/rt_cache
net/snmp
net/snmp6
net/sockstat
net/sockstat6
net/softnet_stat
net/stat/arp_cache
net/stat/ndisc_cache
net/stat/nf_conntrack
net/stat/rt_cache
net/tcp
net/tcp6
net/udp
net/udp6
net/udplite
net/udplite6
net/unix

David, could you comment on this?

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/