netdev - Re: [PATCH] netfilter: xt_condition: add security capability support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1282589101.7198.28.camel@powerslave>
Date:	Mon, 23 Aug 2010 21:45:01 +0300
From:	Luciano Coelho <luciano.coelho@...ia.com>
To:	ext Jan Engelhardt <jengelh@...ozas.de>
Cc:	ext Changli Gao <xiaosuo@...il.com>,
	"kaber@...sh.net" <kaber@...sh.net>,
	"netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	James Morris <jmorris@...ei.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] netfilter: xt_condition: add security capability
 support

On Mon, 2010-08-23 at 16:34 +0200, ext Jan Engelhardt wrote:
> On Monday 2010-08-23 15:42, Luciano Coelho wrote:
> >> >  /* Defaults, these can be overridden on the module command-line. */
> >> >  static unsigned int condition_list_perms = S_IRUGO | S_IWUSR;
> >> >  static unsigned int condition_uid_perms = 0;
> >> >  static unsigned int condition_gid_perms = 0;
> >> > +static unsigned int condition_capabilities = CAP_NET_ADMIN;
> >> >
> >> It is strange that we set security policy in this way. Maybe the
> >> permission of the proc file is enough in this case.
> >
> >Yes, that is another way to do it.  But in our device we use security
> >capabilities more extensively than normal file permissions.  That's why
> >we need this.
> >
> >If this is too restrictive (ie. having CAP_NET_ADMIN) for most users, we
> >could change the default value to no capabilities needed.  Then we can
> >set CAP_NET_ADMIN when loading the module.
> 
> But it looks as strange as the Yama code attempt.

What is so strange about it? Is it because it's possible to set the
capability requirement from modprobe arguments? The capability check
already exists in at least in nfnetlink, where it checks for received
messages for the CAP_NET_ADMIN capability.  Is it strange because we're
checking for the capability when someone tries to write to a file?


>  This is the one time 
> where I would personally be looking into SELinux, or perhaps SMACK if 
> the former is too complex, to whether _t'ing off procfs is possible.

Yeah, but it's not up to me to decide this.  We have one entire team
dedicated to figuring out how to ensure "security" in our device.  It
was that team who advised us to protect this file by checking for
CAP_NET_ADMIN.


-- 
Cheers,
Luca.

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