linux-kernel - Re: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG

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: <20130524222058.GA32409@mtj.dyndns.org>
Date:	Sat, 25 May 2013 07:20:58 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	"James E.J. Bottomley" <JBottomley@...allels.com>,
	Jens Axboe <axboe@...nel.dk>,
	lkml <linux-kernel@...r.kernel.org>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: Re: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization
 of the SG_IO command whitelist (CVE-2012-4542))

On Fri, May 24, 2013 at 11:45:33AM +0200, Paolo Bonzini wrote:
> > It's not just unimplemented commands. Exposing any new command exposes
> > its borderline problems together with it.
> 
> For commands that are used by Linux already, the right way to fix the
> problems is not obscuring the commands from userspace's view.  You can
> hit the same problems with ioctls or even with normal operation of the
> device.

The kernel is providing an isolation layer between the userland and
the devices.  It isn't obscuring.  We can go through many adjectives
but it's still increasing the amount exposed surface and accelerating
expansion of cdb filter.

> And prohibiting the extension of whitelists is gonna increase the
> usage of unpriv_sgio and less-secure userspace whitelists.
> 
> Anvil, meet hammer.

Delegating full device access is still a fringe use case compared to
generic block RW access.  Given thta we're expecting to have an extra
separation layer albeit in userland, the overall picture doesn't seem
to favor extension of whitelists.

> > If the bulk of filtering can be solved with userland whitelisting as a
> > confined user, it should be possible to resolve peripheral problems
> > like log messages in simpler way, no? Can you please elaborate on the
> > log message problem? Who's spewing those messages?
> 
> For example:
> 
>         if (bdev_write_same(bdev)) {
>                 unsigned char bdn[BDEVNAME_SIZE];
> 
>                 if (!blkdev_issue_write_same(bdev, sector, nr_sects, gfp_mask,
>                                              ZERO_PAGE(0)))
>                         return 0;
> 
>                 bdevname(bdev, bdn);
>                 pr_err("%s: WRITE SAME failed. Manually zeroing.\n", bdn);
>         }
> 
>         return __blkdev_issue_zeroout(bdev, sector, nr_sects, gfp_mask);
> 
> The device exposes the ability to zero out LUN blocks, but the command is
> not whitelisted and it fails.

Which can be solved by userland filtering, right?

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