On Tuesday 25 January 2005 13:44, you wrote:
: On Maw, 2005-01-25 at 09:29, Elias da Silva wrote:
: > On Tuesday 25 January 2005 01:01, you wrote:
: > Yes, sometimes you have to risk broken software in favor of augmented
: > security, but so far we only have broken software.
:
: Well let me see in 2.6.5 if you could read open the block device at all
: you could erase the drive firmware. I think we've significantly improved
: security actually.
Alan, please don't let us loose focus!
I'm talking about the classification of the opcodes
a. GPCMD_SEND_KEY and
b. GPCMD_SET_STREAMING
as only "save for write" in scsi_ioctl.c:verify_command()
since kernel version 2.6.8.
The intended security improvements of this restriction can be
completed circumvented by using
a. cdrom_ioctl (..., DVD_AUTH,...) instead of
b. cdrom_ioctl (..., CDROM_SEND_PACKET,...)
so the result is as described:
"no security improvements at the cost of broken software".
The changes looked random to me and I would like to see
a clear concept, which would drive the necessary changes for
improved security and stability.
I'm putting my finger on some loose ends below drivers/cdrom,
drivers/ide and drivers/block.
Regards,
Elias
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
