All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Eric Paris <eparis@redhat.com>
Cc: linux-ext4@vger.kernel.org, selinux@tycho.nsa.gov,
	sds@tycho.nsa.gov, esandeen@redhat.com, tytso@mit.edu,
	dwalsh@redhat.com, linux-security-module@vger.kernel.org
Subject: Re: ext4_has_free_blocks always checks cap_sys_resource and makes SELinux unhappy
Date: Fri, 24 Oct 2008 11:56:09 -0500	[thread overview]
Message-ID: <4901FE29.3090600@redhat.com> (raw)
In-Reply-To: <1224860735.3404.74.camel@localhost.localdomain>

Eric Paris wrote:
> I'm running an ext4 root filesystem and regularly get SELinux denials
> like:
> 
> Oct 16 08:32:55 localhost kernel: type=1400 audit(1224160369.076:5):
> avc: denied  { sys_resource } for  pid=1624 comm="dbus-daemon"
> capability=24 scontext=system_u:system_r:system_dbusd_t:s0
> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=467216
> 
> Since this doesn't happen with people who have ext3 filesystems but
> everything else the same it lead me to look at ext4.  I see that
> ext?_has_free_blocks() has changed since ext3 and now we always check
> for capable(CAP_SYS_RESOUCE).  If a process actually has the capability
> in pE (as many root processes would) but doesn't have the capability in
> SELinux policy we will get a denial.
> 
> I can think of a couple ways to fix this:
> 
> the first (and one I like) is to change ext4 to stop checking
> CAP_SYS_RESOURCE all the time.  It's not really 'pretty' but I think you
> would actually get a better performing function.  Just always calculate
> root_blocks and if we don't have enough room then then do the whole
> check to see if are root and recalculate without root_blocks.  I'd guess
> that a great majority of the time operations will succeed even with a
> non-zero root_blocks and I would guess that most process aren't going to
> be root processes and so we would be calculating root_blocks anyway.
> This would (like ext3) only cause these denials when it was filled up.
> We've been living with that forever, so I don't see a problem there...

Thanks Eric, I'll look into this.  It seems that ext4_has_free_blocks is
now overly complex; it used to return how many blocks are available, if
that number is < nblocks, but the single caller now only checks
success/failure for having nblocks free.  I'll see if I can simplify it
and delay the cap check as you suggest.

-Eric

  parent reply	other threads:[~2008-10-24 16:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-24 15:05 ext4_has_free_blocks always checks cap_sys_resource and makes SELinux unhappy Eric Paris
2008-10-24 15:05 ` Eric Paris
2008-10-24 15:08 ` Stephen Smalley
2008-10-24 15:08   ` Stephen Smalley
2008-10-24 17:28   ` Eric Paris
2008-10-24 17:28     ` Eric Paris
2008-10-24 17:38     ` Stephen Smalley
2008-10-24 17:38       ` Stephen Smalley
2008-10-24 16:56 ` Eric Sandeen [this message]
2008-10-24 19:00   ` Mingming Cao
2008-10-24 19:02     ` Eric Sandeen
2008-10-27  1:39 ` Eric Sandeen

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=4901FE29.3090600@redhat.com \
    --to=sandeen@redhat.com \
    --cc=dwalsh@redhat.com \
    --cc=eparis@redhat.com \
    --cc=esandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=tytso@mit.edu \
    /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.