linux-ext4 - Re: ext4_has_free_blocks always checks cap_sys

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: <1224869922.9353.11.camel@moss-spartans.epoch.ncsc.mil>
Date:	Fri, 24 Oct 2008 13:38:42 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Eric Paris <eparis@...hat.com>
Cc:	linux-ext4@...r.kernel.org, selinux@...ho.nsa.gov,
	esandeen@...hat.com, tytso@....edu, dwalsh@...hat.com,
	linux-security-module@...r.kernel.org
Subject: Re: ext4_has_free_blocks always checks cap_sys_resource and makes
	SELinux unhappy

On Fri, 2008-10-24 at 13:28 -0400, Eric Paris wrote:
> On Fri, 2008-10-24 at 11:08 -0400, Stephen Smalley wrote:
> > On Fri, 2008-10-24 at 11:05 -0400, Eric Paris wrote:
> 
> > > Do others have thoughts?
> > 
> > Seems similar to the vm_enough_memory() case, where we likewise
> > introduced a separate security hook that internally checks without
> > auditing.
> > 
> > The OOM killer likewise ought to be using a non-auditing form of
> > capability checks.
> 
> So would you suggest a generic non-auditing capability checking
> mechanism or a specific hook for "things to use"
> 
> * capable_noaudit(current, cap)
> * security_capable_noaudit(current, cap)
> * security_cap_sys_resource(current)
> 
> Looks like oom also checks CAP_SYS_ADMIN so maybe a generic cap
> interface would be best.

In the vm_enough_memory() case, I think it was Alan Cox's idea to take
the entire policy logic into a distinct security hook so that you could
ultimately support policy-based resource constraints.  Versus only
introducing a non-auditing variant of the capable check.  If we wanted
to be consistent, we'd likewise introduce distinct hooks for these cases
and take more of the logic into them, not just the capability check.
I'm open to either approach though.

> esandeen: I still think it would be a good idea to simplify
> ext4_claim_free_blocks() and ext4_has_free_blocks() which seems to have
> a lot of code duplication and both have the unconditional capable
> calls...

-- 
Stephen Smalley
National Security Agency

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html