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: <1224869312.3404.80.camel@localhost.localdomain>
Date:	Fri, 24 Oct 2008 13:28:32 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Stephen Smalley <sds@...ho.nsa.gov>
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 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.

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

-Eric

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ