Hi,
I guess subject says it all - why is FIBMAP ioctl restricted only to
root (CAP_SYS_RAWIO)? Corresponding ioctl for XFS is allowed without any
special capabilities so we are inconsistent here too...
Would anyone mind if the check is removed?
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
On Thu, 22 Nov 2007 19:17:14 +0100
Jan Kara <[email protected]> wrote:
> Hi,
>
> I guess subject says it all - why is FIBMAP ioctl restricted only to
> root (CAP_SYS_RAWIO)? Corresponding ioctl for XFS is allowed without
> any special capabilities so we are inconsistent here too...
> Would anyone mind if the check is removed?
probably principle of least privilege; the location on physical media
for a file is clearly something internal to the OS, and non-trusted
users normally don't have any business knowing that.
I can't think of any immediate exploitable thing with it, but I'm sure
attackers would find a way to use it to increase their privilege once
they can do something like "write 512 bytes to a disk address of my
choice".. (but then again it's game over mostly already)
>
> Honza
--
If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Thu, Nov 22, 2007 at 07:17:14PM +0100, Jan Kara wrote:
> Hi,
>
> I guess subject says it all - why is FIBMAP ioctl restricted only to
> root (CAP_SYS_RAWIO)? Corresponding ioctl for XFS is allowed without any
> special capabilities so we are inconsistent here too...
> Would anyone mind if the check is removed?
Once upon a time some filesystems fucked up when incorrect values
(negative offsets in particular). So the easy way out was taken and
FIBMAP was restricted, to the eternal annoyance of DVD players which
needed the sector number for CSS reasons. Since then dvd players have
included an udf parser and life went on.
Well, psx movie players needed it too, but bah.
Essentially if you remove the restriction you have to audit all
filesystems to be sure that they're not going to be problematic.
OG.
Original thread btw:
http://www.ussg.indiana.edu/hypermail/linux/kernel/9907.0/0132.html
OG.
On Thu, 22 Nov 2007 19:17:14 +0100
Jan Kara <[email protected]> wrote:
> Hi,
>
> I guess subject says it all - why is FIBMAP ioctl restricted only to
> root (CAP_SYS_RAWIO)? Corresponding ioctl for XFS is allowed without any
> special capabilities so we are inconsistent here too...
> Would anyone mind if the check is removed?
It would be great if it was but it involves a *lot* of work.
Alan
> probably principle of least privilege; the location on physical media
> for a file is clearly something internal to the OS, and non-trusted
> users normally don't have any business knowing that.
FIBMAP isn't correctly locked against misuse, and that requires FIBMAP is
safe against truncate and relocation. There was thread on l/k about this
a month ago or so.
Its also the wrong API (32bit, no notion of extents, compression etc)
On Thu, Nov 22, 2007 at 07:56:20PM +0000, Alan Cox wrote:
> > probably principle of least privilege; the location on physical media
> > for a file is clearly something internal to the OS, and non-trusted
> > users normally don't have any business knowing that.
>
> FIBMAP isn't correctly locked against misuse, and that requires FIBMAP is
> safe against truncate and relocation. There was thread on l/k about this
> a month ago or so.
>
> Its also the wrong API (32bit, no notion of extents, compression etc)
The right approach would be to create a new syscall, and a new entry
point in the inode operations table, and filesystems could provide
support for the new system call as their bmap code was audited for
correctness.
For bonus points the new interface would also provide make it more
efficient for filesystems to return information about extents. (i.e.,
Not only is logical block 150 mapped to physical block 5550, it is
part of an 200 block extent starting at logical block 0 to physical
block 5400.)
- Ted