All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Christoph Hellwig <hch@infradead.org>,
	Paul Moore <paul@paul-moore.com>,
	Eric Paris <eparis@parisplace.org>,
	selinux@tycho.nsa.gov
Subject: Re: [PATCH v2 1/2] security: Add hook to invalidate inode security labels
Date: Tue, 6 Oct 2015 17:29:30 -0400	[thread overview]
Message-ID: <56143D3A.3010802@tycho.nsa.gov> (raw)
In-Reply-To: <CAHc6FU78E-aTZP9gw51iO3e277AZ1UA7R-_Qw8Bwe=idJ=qmbg@mail.gmail.com>

On 10/05/2015 05:56 PM, Andreas Gruenbacher wrote:
> On Mon, Oct 5, 2015 at 5:08 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> Not fond of these magic initialized values.
> 
> That should be a solvable problem.
> 
>> Is it always safe to call inode_doinit() from all callers of
>> inode_has_perm()?
> 
> As long as inode_has_perm is only used in contexts in which a file
> permission check / acl check would be possible, I don't see why not.
> 
>> What about the cases where isec->sid is used without going through
>> inode_has_perm()?
> 
> inode_has_perm seems to be called frequently and invalid labels seem
> to be reload quickly, so this change may make SELinux work well enough
> to be useful on top of gfs2 or similar. More checks would of course be
> better. The ideal case would be to always reload invalid labels, but
> that currently won't be possible because we don't have dentries
> everywhere.
> 
> I can't tell if this is this good enough to provide a useful level of
> protection. In any case, without a patch like this, on gfs2 and
> similar file systems, SELinux currently doesn't work at all.
> 
> How we can make progress with this problem?

I think we'd need to wrap all uses of inode->i_security with a helper that
applies this test.  FWIW, many/most of them seem to have a dentry
available, including all callers of inode_has_perm itself, so you could
just use inode_doinit_with_dentry() for all of those cases.  Maybe just
inline inode_has_perm() and get rid of it.

Need to deal appropriately with situations like selinux_inode_permission with
MAY_NOT_BLOCK.

  reply	other threads:[~2015-10-06 21:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-04 19:19 [PATCH v2 0/2] Inode security label invalidation Andreas Gruenbacher
2015-10-04 19:19 ` [PATCH v2 1/2] security: Add hook to invalidate inode security labels Andreas Gruenbacher
2015-10-05 15:08   ` Stephen Smalley
2015-10-05 15:08     ` Stephen Smalley
2015-10-05 21:56     ` Andreas Gruenbacher
2015-10-06 21:29       ` Stephen Smalley [this message]
2015-10-05 18:24   ` Casey Schaufler
2015-10-05 18:39     ` Andreas Gruenbacher
2015-10-04 19:19 ` [Cluster-devel] [PATCH v2 2/2] gfs2: Invalide security labels of inodes that go invalid Andreas Gruenbacher
2015-10-04 19:19   ` Andreas Gruenbacher

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=56143D3A.3010802@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=agruenba@redhat.com \
    --cc=eparis@parisplace.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=selinux@tycho.nsa.gov \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.