On 01/22/2014 07:33 PM, Negreanu, Adrian M wrote:
On Wed, Jan 22, 2014 at 11:18 AM, Carsten Haitzler
<[email protected] <mailto:[email protected]>> wrote:
On 01/22/2014 06:10 PM, Negreanu, Adrian M wrote:
On Wed, Jan 22, 2014 at 10:55 AM, Carsten Haitzler
<[email protected] <mailto:[email protected]>> wrote:
On 01/22/2014 05:46 PM, Negreanu, Adrian M wrote:
On Wed, Jan 22, 2014 at 1:58 AM, Carsten Haitzler
<[email protected] <mailto:[email protected]>> wrote:
On Tue, 21 Jan 2014 11:28:03 -0800 Ryan Ware
<[email protected] <mailto:[email protected]>> said:
> Tue, Jan 21, 2014 at 2:01 AM, Jussi Laako
<[email protected]
<mailto:[email protected]>>wrote:
>
> > On 21.1.2014 10:38, José Bollo wrote:
> >
> >> IMHO, SDB is integrated with the developer tools
and that is really
> >> good. But it is not sure at all: you can become
root on the device
> >> without being asked for any password, just a USB
cable is needed. Also
> >> SDB is a component that is not common, not proven,
not linked to PAM,
> >> and, that must be maintained at our cost. Just my 2
coins.
> >>
> >
> > SDB should require enabling developer mode on the
device itself, it
> > shouldn't be enabled by default. Just like ADB (or
whatever it was called)
> > on my Android devices. I've enabled it once to flash
CyanogenMOD.
> >
>
> SDB should definitely not be on by default. Doing so
goes against a number
> of different security principals including reducing
attackable surface area
> and least privilege.
sure - but same applies for ssh. the difference is that
when i enable developer
mode on my device. do some work, go to lunch with my
phone and someone borrows
it for 10 mins (plugs into usb and starts messing
around) they can do so with no
auth at all. zero. if sdb were to turn off every time a
phone is unplugged
we'll have insanely annoyed developers continually
finding menus to turn it on
and eventually deciding tizen is is more pain than
anything else.
How about being asked for a password when the USB cable is
plugged in ?
For Android, you get a notification and you can choose
whether you enabled debug mode or not,
which as you say, is not safe.
Instead, you may be asked for a developer password and avoid
digging through menus.
Also, I find sdbd useful when bringing up new platforms,
where network connectivity is not ready yet.
how is network connectivity not there? usb network gadget has
been in the kernel as long as i've been doing phone stuff
(since at least 2008). the kernel emulates a network usb
device. you don't need wifi and other network.
I think we're viewing the problem from two different point of views.
I'm more interested in a device in the "bring-up" stage where you
might not have OTG ready(thus no USB gadgets),
whereas (I assume) you're interested in a device that's well
after the "bring-up" stage.
For the latter, when everything works fine, SDBD is indeed optional.
but sing sdb uses the same usb gadget interface to advertise
effectively what is a serial device over usb (i don't know it's
details - but it must logically appear as some custom type/class
of usb device) .. thus it has the same basic requirements of a
kernel at this level? sure - you dont need userspace to CONFIGURE
the usbnet device (ip address, route etc.) for sdb and that is
indeed simpler at this stage - but at the usb/kernel level isn't
it basically the same?
True, the ADB/SDB driver is a serial usb gadget. I assumed that you
were talking to plugin in an ethernet-over-usb dongle
into the phone, but that obviously wasn't the case.
I dug up some more to see why my device wasn't found as an usb0 device
and it turned out I didn't specified
"rndis" in usb_mode/usb0/functions (my bad).
yeah - i was just thinking raw usb cable from device to host. same thing
sdb uses/needs. :)
as for password - ask on the device screen?
Yup, on the device screen. This means that when I'm not in
graphical run-level, I can use SDBD w/o being asked for
a password.
i suspect that woould become most infuriating to have to enter it
every time on the phone rather than via the far more useful
keyboard i have in front of me right now ... :)
true. considering "i can has" network in the bring-up stage, this
isn't needed anymore
Though, there is one more use case for sdb: forwarding unix sockets
onto the workstation.
sdb does this? or you mean tcp sockets? i've used ssh to fwd tcp sockets
all around the place often enough - i've never had to fwd a unix socket
before. generally a unix socket is machine dependent - eg its a comms
channel but you may be talking about other shared resources like shm
segments, fd passing drm buffers around and you make assumptions that
when you talk on a unix socket you are on the same arch - so
endianess/alignment etc. are the same. so i generally would see a fwd of
unix sockets as "not commonly usefule due to the assumptions placed on
unix sockets". :)
--
Adrian Marius Negreanu
Intel Open Source Technology Center
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
