[Sugar-devel] Fwd: Regarding the print support idea(GSoC)

[Vamsi Krishna Davuluri]

True enough, but I hadn't been talking about printing from activities
directly at all for the last half of the mails. :<
But for even CUPS to act as a server and accept incoming requests, it would
have to excercise freedom to one port atleast, but write a bit of a code so
that it accepts requests only from local network which ever was configured
on the router. ;) And, we could specify certain pool of ips which are to
access the print server.

On Wed, Mar 18, 2009 at 7:06 PM, Luke Faraone <luke at faraone.cc> wrote:

>
>
>  On Wed, Mar 18, 2009 at 9:28 AM, Vamsi Krishna Davuluri <
> vamsi.davuluri at gmail.com> wrote:
>
>>
>> The link you gave didn't work, so I checked this page
>> http://wiki.laptop.org/go/OLPC_Bitfrost
>> I have gone through security models listed, umm ... was there anything
>> specific I was to look into?
>>
>>>   Well,
>
>
>>      I'd grant them only if the user is the owner of that specific
>>>> document or is master root. This will be most useful in case the machine
>>>> acts as a cups server and a request comes from the network, we could see
>>>> that other than the local master, no one else on the network has access to
>>>> that particular job, or stop that printing event from taking place.
>>>>
>>>
> As far as I am aware, this is the default CUPS behavior.
>
>       btw thought of another thing, when the print button is clicked in an
>>>> activity, the request metadata (object) is sent to the journal, but the
>>>> journal doesnt have to immediately take over control, instead  within the
>>>> activity a pop up comes which says 'print jobs in queue('this can be closed,
>>>> or clicked to go to the journal where the job can be canceled, or started)
>>>> and when loging in into sugar, if pending jobs are there again a
>>>> notification is displayed, and if a print job is of a particular activity,
>>>> and they are pending, and if the same activity is opened again it
>>>> notification is displayed.
>>>>
>>>  And are the implementations not prone to modification?
>> As in we could specify a particular #print_port to bypass them?
>>
>
> Allowing activities to print things directly is just asking for trouble.
> Potential attack vector: an activity that has RO access to all documents but
> is denied net access (per their mutual-exclusiveness specified by bitfrost)
> has the ability to send outgoing requests to port 5900 (HP JetDirect port),
> per your printing exception. A black hat, who authored this application,
> sets up a "print server" at death.example.com. Since the activity can send
> any packet it wishes on that port, it simply "prints" to this server. The
> attacker now has subverted the bitfrost model, and now has access to all of
> the user's documents.
>
>
> --
> Luke Faraone
> http://luke.faraone.cc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090318/29ce0cf9/attachment.htm