linux-kernel - Re: security_inode_init_security() inode field requirements

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: <1362152324.2723.32.camel@menhir>
Date:	Fri, 01 Mar 2013 15:38:44 +0000
From:	Steven Whitehouse <swhiteho@...hat.com>
To:	Eric Paris <eparis@...isplace.org>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Mimi Zohar <zohar@...ibm.com>,
	Chris Wright <chrisw@...s-sol.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	cluster-devel@...hat.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: security_inode_init_security() inode field requirements

Hi,

On Fri, 2013-03-01 at 10:13 -0500, Eric Paris wrote:
> SELinux has no maximum   :-(
> 
> Realistically there are a couple of interfaces that limit things to
> 4k, but labels on files on disk could be even larger than that!
> 
> 255 will fit most every label, but not necessarily all of them.
> 
> 
> I know ext4 on Fedora allocates inodes which left about 255 bytes for
> selinux.selinux, but will place the xattr in another block if it
> happens to be larger than 255.  This is rare, but certainly
> possible....
> 
> We use the inode->i_mode.
> 
> In debug/error path we use:
>   inode->i_sb inode->i_no
> 
> We could use the parent dir sb instead of the new inode->i_sb.  We
> don't have to print the i_no when we hit a failure, but it is just
> about the only information that can help for debugging/figuring out
> which file had a failure..
> 
> -Eric
> 
So it sounds like setting the selinux label before the allocation of the
inode wouldn't be too much of a problem. That would give us the size
ahead of time. Maybe EVM is the only thing which needs to be an
exception in terms of being done after the inode number is set, and if
that has a fairly small maximum size, then that could still work I
think.

Having said that, this is turning out to be a fair bit more complicated
than I'd hoped :(

Steve.




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