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
| ||
|
Message-ID: <20071026215550.GA27037@aurum.uhlenkott.net> Date: Fri, 26 Oct 2007 14:55:50 -0700 From: Jason Uhlenkott <jasonuhl@...onuhl.org> To: Alan Cox <alan@...rguk.ukuu.org.uk> Cc: Mike Waychison <mikew@...gle.com>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, Linux Kernel <linux-kernel@...r.kernel.org> Subject: Re: [patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP On Fri, Oct 26, 2007 at 01:22:17 +0100, Alan Cox wrote: > On Thu, 25 Oct 2007 16:06:40 -0700 > Mike Waychison <mikew@...gle.com> wrote: > > > Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open file descriptor. > > > > It would be nice to allow users to have permission to see where their data is landing on disk, and there really isn't a good reason to keep them from getting at this information. > > Historically this was done because people felt it was more secure. It > also allows you to make some deductions about other activities on the > disk but thats probably only a concern for very very security crazed > compartmentalised boxes > > Also historically at least FIBMAP could be abused to crash the system. > Now if you can verify that has been fixed I have no problem, but given > that I can find no record of that being fixed it would be wise to audit > it first and review Chris Evans and other reports about what occurs when > FIBMAP is passed random block numbers. > > FIBMAP has another problem for this general use as well - it takes an int > but the block number can now be bigger for very large files on 32bit. Additionally, ext3_bmap() has this to say about it: if (EXT3_I(inode)->i_state & EXT3_STATE_JDATA) { /* * This is a REALLY heavyweight approach, but the use of * bmap on dirty files is expected to be extremely rare: * only if we run lilo or swapon on a freshly made file * do we expect this to happen. * * (bmap requires CAP_SYS_RAWIO so this does not * represent an unprivileged user DOS attack --- we'd be * in trouble if mortal users could trigger this path at * will.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists