netdev - Re: [RFC PATCH v1 0/2] The Long Lost TUN LSM Hooks

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LRH.2.00.0908051035530.29562@tundra.namei.org>
Date:	Wed, 5 Aug 2009 10:43:03 +1000 (EST)
From:	James Morris <jmorris@...ei.org>
To:	Paul Moore <paul.moore@...com>
cc:	netdev@...r.kernel.org, linux-security-module@...r.kernel.org,
	selinux@...ho.nsa.gov
Subject: Re: [RFC PATCH v1 0/2] The Long Lost TUN LSM Hooks

On Tue, 4 Aug 2009, Paul Moore wrote:

> While drivers in general aren't good places for LSM hooks the TUN driver is
> a bit different because of how it handles sockets and network traffic.  The
> problem lies in the fact that the TUN driver creates a sock structure to use
> when sending network traffic but the sock is never put through the same LSM
> setup/control as other sock structures on the system which makes enforcing
> security on TUN generated traffic difficult for some LSMs.  This patch set
> adds three new LSM hooks, all specific to the TUN driver (none of the existing
> hooks made sense, trust me we tried), to control and monitor the creating and
> attachment of TUN devices.

Looks ok to me in principle.

For netdev reviewers: we're lacking proper LSM control over tun devices 
because they're not created like normal sockets, and subsequently don't 
get labeled appropriately.  They also behave differently to normal sockets 
and need special handling for security per Paul's notes.


- James
-- 
James Morris
<jmorris@...ei.org>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html