R: [gst-devel] Create a secure level

Domenico Pontari D.Pontari at ELIS.ORG
Tue May 3 09:37:00 CEST 2005

Ok, I would like to go deeper in the short answer. What do you think about a security check on:

1) player
2) Gstreamer
3) X Windows

in the player there is a parity check on Gstreamer and X Windows, in GStreamer API's there is a parity check on the player and X Windows (and I could say: in X Windows there is a parity check on Gstreamer and the player).
So that when you try to exploit the player it doesn't work because Gstreamer's parity check fails, when you try to exploit Gstreamer it doesn't work because the parity check of the player fails. The only way to solve the trick is to patch Gstreamer and the player together: it should be complex because you don't know if you failed in Gstreamer or in the player. If you do this for XWindows too, it should be quite impossible.

I'm agree with you that many other problems remain (for example hardware/phisical attacks), but I would like only fix the bigger hole at the moment: creating patches is more difficult that using a program like camtasia.


-----Messaggio originale-----
Da: Jan Schmidt [mailto:thaytan at noraisin.net]
Inviato: martedì 3 maggio 2005 13.49
A: Domenico Pontari
Cc: gstreamer-devel at lists.sourceforge.net
Oggetto: Re: [gst-devel] Create a secure level

On Mon, 2005-05-02 at 12:27 +0200, Domenico Pontari wrote:
> Do you think is possibile creating a secure level with GStreamer, 
> so that when an apllication use a pipeline another cannot record from them? 
> This should be an useful way to protect video from local recording.
> Thanks,
> Domenico

Hi Domenico,

The short answer is "No" - it's impossible with today's computer
hardware to ensure that there is no way to record the video. The problem
is that at some point you have to trust some piece of code that you
haven't written, and that other piece of software might be replaced by
the user.

For example, any player on Linux has to eventually hand the uncompressed
video images to the X Server to display, and a user that REALLY wants to
capture the stream (and has enough talent) can modify their X Server and
recompile it.

Even on MS Windows, people can do things like that though, it's just
generally too much effort. (Before DeCSS, hooking into DLLs and
capturing the uncompressed video was the way they copied DVDs)

If you're writing your own player, then the pipelines you're using are
not easily accessible from outside the application - provided they
haven't modified their GStreamer installation - which makes copying the
original compressed data harder to achieve. 

The plugin locking mechanism that we're thinking of will make it so that
if you have custom elements for handling a proprietary codec, only
applications with permission will be able to use that plugin. 

In the end though, the X Server will still have access to the
uncompressed video for display which makes programs like camtasia hard
to prevent.

I'll post some more on the plugin-locking stuff a little later - there's
a plugin locking document that I've been working on that's been on the
backburner too long.
Jan Schmidt <jan at fluendo.com>

More information about the gstreamer-devel mailing list