linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: Eric Paris <eparis@parisplace.org>
Cc: cluster-devel@redhat.com, Mimi Zohar <zohar@us.ibm.com>,
	Mailing List <linux-kernel@vger.kernel.org>,
	Chris Wright <chrisw@sous-sol.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	Linux@redhat.com, linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>
Subject: Re: security_inode_init_security() inode field requirements
Date: Fri, 01 Mar 2013 15:38:44 +0000	[thread overview]
Message-ID: <1362152324.2723.32.camel@menhir> (raw)
In-Reply-To: <CACLa4psWBYPDjiZB3ROA4yGTbJX=UmN3Go8xH_myZ+_W7D01AA@mail.gmail.com>

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.

  reply	other threads:[~2013-03-01 15:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-01 10:12 security_inode_init_security() inode field requirements Steven Whitehouse
2013-03-01 12:27 ` Mimi Zohar
2013-03-01 13:11   ` Steven Whitehouse
2013-03-01 14:07     ` Mimi Zohar
2013-03-01 15:13       ` Eric Paris
2013-03-01 15:38         ` Steven Whitehouse [this message]
2013-03-03 19:12 ` Casey Schaufler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1362152324.2723.32.camel@menhir \
    --to=swhiteho@redhat.com \
    --cc=Linux@redhat.com \
    --cc=chrisw@sous-sol.org \
    --cc=cluster-devel@redhat.com \
    --cc=eparis@parisplace.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=zohar@linux.vnet.ibm.com \
    --cc=zohar@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).