linux-kernel - Re: [RFC PATCH 2/2] SELinux: cache inode checks inside struct inode

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.LFD.2.03.1306040628420.25797@pixel.linux-foundation.org>
Date:	Tue, 4 Jun 2013 06:31:30 +0900 (PWT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Eric Paris <eparis@...hat.com>
cc:	sds@...ho.nsa.gov, linux-kernel@...r.kernel.org,
	selinux@...ho.nsa.gov
Subject: Re: [RFC PATCH 2/2] SELinux: cache inode checks inside struct
 inode

On Mon, 3 Jun 2013, Eric Paris wrote:
>  
>  #ifdef CONFIG_SECURITY
> +	seqcount_t		i_security_seqcount;
> +	u32			i_last_task_sid;
> +	u32			i_last_granting;
> +	u32			i_last_perms;
> +	u32			i_audit_allow;
>  	void			*i_security;
>  #endif

This is much too big. I was really hoping for "another word that the 
security layer can use" or similar. 

Something this big would be acceptable if it would be a *generic* security 
cache, and others could use it too, and would avoid ever actually calling 
into any security layer at all (ie we could do the checks entirely at the 
VFS layer). Then it would be fine. But for just the fact that SELinux is 
too slow? No.

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