Re: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver becauseof worrying about possible misusage?

[Peter martin]

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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/