Torvolds on GPLv3
John Brazel
john at tellurian.com.au
Wed Oct 4 04:16:14 CST 2006
Mark Newton wrote:
> Adam Hawes wrote:
>
>> UNIX file permissions are not a form of DRM. They do not effect the
>> rights of
>> any person who you authorise to read the file. Once that person has
>> read access it's irrevocable if they care to simply copy the file
>> into a location
>> that they control.
>
> Which is kinda the point of cryptographic DRM - It ties the
> permissions to
> the file, so that someone you've granted read access to can't breach your
> security in that way.
UNIX permissions are an example of Access Controls (not DRM). They
determine who is allowed to see the data. DRM controls what a user can
*do* with the data, once they're granted read access to it.
The two are complementary, but by no means the same thing. UNIX
permissions will not stop a user from copying a file they have read
access to, printing it to a printer, or emailing it off-system. DRM (in
an ideal implementation) will prevent this.
Crypto is one means of implementing DRM. Data labling and
marshalling (as found in those whacked out B3 class secure operating
systems developed by the US army in the 70s and 80s) is another. DRM is
not synonymous with crypto (cryptography is one way of attempting to
kludge DRM).
Can we all stop pretending that we're cryptographers and security
experts, for a moment? Ross Anderson's book on Security Engineering is
up on the web and free to download, so there's no excuse for not getting
this straight. While you're there, read everything else Ross has
written on DRM, especially Palladium.
>
> I'm not sure why you view that as a bad thing. Us open-source advocates
> like secure outcomes, don't we? Keeping access permissions out-of-band
> represents a fairly sizable security back-door, doesn't it?
DRM hardware is a fine idea. Where it breaks down is when the
software vendor (eg MS) decides that the owners of the hardware (us)
*shouldn't* get access to the key required to install & run boot
software (in the case of the Xbox).
John
More information about the linuxsa
mailing list