linux-kernel - Re: [patch 1/1] Drop CAP_SYS_RAWIO requirement for FIBMAP

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4722635D.901@google.com>
Date:	Fri, 26 Oct 2007 14:59:57 -0700
From:	Mike Waychison <mikew@...gle.com>
To:	Jason Uhlenkott <jasonuhl@...onuhl.org>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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

Jason Uhlenkott wrote:
> 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.)

Hmm.  I don't know what the right approach to this is.  This seems to be 
the same situation as the delayed allocation problem, no?

What if we just returned 0?  Tools like lilo are already doing sync(), 
would that cause the journal to get flushed explicitly anyway?

Mike Waychison
-
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/