linux-kernel - Re: was once: Samsung DVD writer.

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4616A3E0.4070206@tmr.com>
Date:	Fri, 06 Apr 2007 15:47:44 -0400
From:	Bill Davidsen <davidsen@....com>
To:	scdbackup@....net
CC:	cdwrite@...er.debian.org,
	Linux Kernel mailing List <linux-kernel@...r.kernel.org>
Subject: Re: was once: Samsung DVD writer.

scdbackup@....net wrote:
> Hi,
>
> BTW: What happened to "FreeBSD User Giacomo" and his Samsung DVD writer ?
>
> Any news to report ? A happy ending perchance ?
>
>
> Bill Davidsen: [about filtering dangerous SCSI commands]
>   
>> My suggestion would be to add an ioctl, like SET_SCSI_UNFILTERED, which
>> can only be used as root, and which would allow SCSI commands sent a
>> device to be persistently set unfiltered.
>>     
>
> I understand that would be for programs like firmware
> updaters, but not for the vanilla purpose of bringing
> data onto an optical disc ?
>
> Because ... if this is intended for daily usage:
>
> I do not think that burning a disc on a desktop should
> necessarily require root privileges. Let's leave it to
> the sysadmin (or distro) to decide who may burn resp.
> may endanger the device by malicious use of normally
> harmless SCSI commands. (Like overworking the drive tray
> motor ?)
>
>   
I don't see a problem here requiring root. Once the filter is turned off 
for the device, say in rc.local, and the ownership and permissions are 
set, there's no issue. It can be owned by root, group cdwriters, have 
permissions 0660, and cdrecord or other trusted programs can be setgid 
once the kernel stop blocking such access.
> After all, what is gained if one performs daily tasks
> as a privileged user ? That only pierces the protection
> against absent-minded mistakes and involuntary backdoors.
>
>   
No need to do any daily tasks in a dangerous mode, access would be 
limited to users and programs regarded as trusted.
> Actually i try to stay away from any kernel peculiarities
> so i do not get addicted to something that might change.
> A pointer to a list of forbidden commands would be welcome
> thus.
>
>   
If this could be added it would presumably not change.
> Maybe cdrskin was up to now only tested on totally insecure
> systems.  After all i never got reports of the ominous
> command filtering interfering with burning. If it prevents
> any of libburn's SCSI commands from being executed then it
> does this silently and does not prevent burning success.
>   

No, as I noted, programs other than cdrecord are clever enough to avoid 
requiring disallowed commands.
> I would like to know, which commands and cease sending them. :))
>
>
> libburn SCSI command list (commands in brackets are defined
> but not in normal use):
> spc.c: 00h, 03h, 12h, 1Eh, 55h, 5Ah,
> sbc.c: 1Bh,
> mmc.c: 04h, 23h, 2Ah, 35h, 43h, 46h, 4Ah, 
>        51h, 52h, 53h, 54h, 5Bh, 5Ch, 5Dh,
>        A1h,(AAh),ACh, B6h, BBh,(BEh), 
>
>
> Have a nice day :)
>   
I put lkml back on the recipients, I'm suggesting a new ioctl as a way 
around the decision to no longer have setuid/setgid actually fully 
functional.

-- 
bill davidsen <davidsen@....com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

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