Re: [PATCH 1/1] fiemap: move i_op->fiemap() locking to the ioctl_fiemap()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 27, 2012 at 3:35 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> On Thu, Sep 27, 2012 at 10:43:15AM +0300, Kasatkin, Dmitry wrote:
>> On Thu, Sep 27, 2012 at 5:12 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>> > On Wed, Sep 26, 2012 at 11:22:14AM +0300, Kasatkin, Dmitry wrote:
>> > If I were an attacker, I could easily prevent detection from
>> > occurring simply by leaving an open file sitting around. IOWs, open
>> > all the files I wanted to modify, read them, drop the page cachend
>> > then modify the block device directly.  And now the files full of
>> > unverified content will now be certified as valid...
>> >
>>
>> That is online attack. You need to be a root to modify block device directly...
>> But if you already became a root - game over.
>> Online protection is done by access control..
>> IMA protects against offline modification..
>>
>> >> > Seriously, if someone can modify your block device directly then
>> >> > you've already lost and no amount of after-the-fact verification
>> >> > will save you.
>> >>
>> >> Are you talking about offline or online modification?
>> >> Integrity protection against offline modification..
>> >> Online is protected by Access Control...
>> >
>> > Either. Both. It doesn't matter. Someone modifying the block device
>> > directly means they either have already broken your access controls
>> > or they have physical access to your machine.
>> >
>>
>> It is different...
>> You might have physical access to your machine storage but no root access.
>> You could remove storage and plug it to another machine, modify data.
>> For example you could add user to /etc/sudoers or change root password.
>> But when when you plug it back to your machine, IMA verification fails,
>> and you will not be able to become a root.
>
> Three words: Full disk encryption.
>

That is known and always preferred option when hw and battery allows..

> Besides, you're still missing the obvious attack for both online and
> offline attackers: replace the kernel or change kernel command line
> parameters to turn off IMA/EVM verification...
>

I do not miss anything..
That is obvious. All that relies on "secure/trusted boot" when
bootloader & kernel & modules are verified..
And of course user is not able to pass own parameters...

That is also applied to LSM, when user should not be able to disable
SELinux or Smack...

>> >> Are there any ways to detect that any of the pages have been dropped
>> >> from the kernel page cache?
>> >
>> > I don't think there's any reliable method for detecting that as
>> > present.
>>
>>
>> May be inode->i_mapping->nrpages counter might indicate that.
>> mm/filemap.c does ++ or --
>
> Remove a page, add a page. nr_pages is still the same. Not reliable.
>

yes

Thanks
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux