Message-ID: <4EE4FA4A.6030909@naiadhome.com>
Date:	Sun, 11 Dec 2011 18:45:30 +0000
From:	Peter martin <peter@...adhome.com>
To:	unlisted-recipients:; (no To-header on input)
CC:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because
 of worrying about possible misusage?

One thing I have not seen addressed here is security. I've had a brief 
scan of the code, but there does not appear to be any mechanism to 
authenticate/authorise remote access to the vtunerc devices. In a home 
entertainment environment, this is not too serious, but In a non-closed 
network, for example a commercial installation in a hotel, what is to 
stop a rogue client from accessing a tuner and potentially causing 
mischief by changing settings, More seriously pulling a full MPTS of 
decrypted content from a CI card, which would make content providers 
most unhappy!

I don't know enough about kernel modules doing networking, but do the 
packets go through the iptables route, and do things like DSCP still get 
taken note of?

vtunerc sounds like a neat idea, but I am worried by the back doors it 
opens up. Sorry if I've missed something obvious here!

Pete Martin


On 07/12/2011 14:01, Andreas Oberritter wrote:
> On 07.12.2011 14:49, Mark Brown wrote:
>> On Tue, Dec 06, 2011 at 03:48:27PM +0100, Andreas Oberritter wrote:
>>> On 06.12.2011 15:19, Mark Brown wrote:
>>>> Your assertatation that applications should ignore the underlying
>>>> transport (which seems to be a big part of what you're saying) isn't
>>>> entirely in line with reality.
>>> Did you notice that we're talking about a very particular application?
>> *sigh*
>>
>>> VoIP really is totally off-topic. The B in DVB stands for broadcast.
>>> There's only one direction in which MPEG payload is to be sent (using
>>> RTP for example). You can't just re-encode the data on the fly without
>>> loss of information.
>> This is pretty much exactly the case for VoIP some of the time (though
>> obviously bidirectional use cases are rather common there's things like
>> conferencing).  I would really expect similar considerations to apply
>> for video content as they certainly do in videoconferencing VoIP
>> applications - if the application knows about the network it can tailor
>> what it's doing to that network.
>>
>> For example, if it is using a network with a guaranteed bandwidth it can
>> assume that bandwidth.  If it knows something about the structure of the
>> network it may be able to arrange to work around choke points.
>> Depending on the situation even something lossy may be the answer - if
>> it's the difference between working at all and not working then the cost
>> may be worth it.
> Once and for all: We have *not* discussed a generic video streaming
> application. It's only, I repeat, only about accessing a remote DVB API
> tuner *as if it was local*. No data received from a satellite, cable or
> terrestrial DVB network shall be modified by this application!
>
> Virtually *every* user of it will use it in a LAN.
>
> It can't be so hard to understand.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message tomajordomo@...r.kernel.org
> More majordomo info athttp://vger.kernel.org/majordomo-info.html


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

Powered by blists - more mailing lists