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 <l...@faraone.cc> wrote: > > > On Wed, Mar 18, 2009 at 9:28 AM, Vamsi Krishna Davuluri < > vamsi.davul...@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 >
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel