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

Powered by blists - more mailing lists