netdev - Re: [RFC PATCH v1 2/2] selinux: Support for the new 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: <7e0fb38c0908050606o2aa1a718x599c101592ec1ce8@mail.gmail.com>
Date:	Wed, 5 Aug 2009 09:06:56 -0400
From:	Eric Paris <eparis@...isplace.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 2/2] selinux: Support for the new TUN LSM hooks

On Tue, Aug 4, 2009 at 5:22 PM, Paul Moore<paul.moore@...com> wrote:
> Add support for the new TUN LSM hooks: security_tun_dev_create(),
> security_tun_dev_post_create() and security_tun_dev_attach().  This includes
> the addition of a new object class, tun_socket, which represents the socks
> associated with TUN devices.  The _tun_dev_create() and _tun_dev_post_create()
> hooks are fairly similar to the standard socket functions but _tun_dev_attach()
> is a bit special.  The _tun_dev_attach() is unique because it involves a
> domain attaching to an existing TUN device and its associated tun_socket
> object, an operation which does not exist with standard sockets and most
> closely resembles a relabel operation.
>
> This patch also includes a new policy capability, tun_perms, to ensure that
> the new access controls do not affect older SELinux policies.

I think we finally have the first patch where the 'handle_unknown'
stuff fits better than the policy capabilities work!  First time for
everything!  I'd suggest dropping the policy capability all together
and the checks will be applied when the class and perm is defined in
the loaded policy.  If the class+perm isn't defined in policy the
policy handle_unknown setting will define the result of the security
check.

whoo hoo, saves 32bits of memory and 2 branches on low use operations!

-Eric
--
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