**** BEGIN LOGGING AT Fri Oct 14 02:59:58 2016
Oct 14 06:24:01 <PaulFertser> DocScrutinizer05: the thing is, udev doesn't really probe for devices. If you have a hid keyboard driver already loaded (for real external keyboard) and the modem suddenly changes into being a keyboard too, the kernel will bind the driver right away, without udev's help.
Oct 14 06:24:30 <DocScrutinizer05> hmmm
Oct 14 06:24:31 <PaulFertser> DocScrutinizer05: so that's a major requirement you'll have to pass to your kernel hackers. It's not trivial and not out of the box.
Oct 14 06:26:18 <DocScrutinizer05> I thought there's a 2 layer setup: HID/whatever *on top* of a generic USB driver that only handles enum and physical data transfer
Oct 14 06:26:41 <DocScrutinizer05> like, musb-hdrc ;-)
Oct 14 06:27:25 <PaulFertser> Yes, there's a kernel usb host controller driver that does enum etc. And usb devices drivers that are in-kernel too. Can be bound without udev.
Oct 14 06:29:39 <DocScrutinizer05> so we need to keep the usb driver (musb-hdrc, ehci, ohci, uhci (?) whatever) but teach whom? kernel? to not bind a device driver on top of that automatically for this one USB port?
Oct 14 06:31:24 <PaulFertser> Yes, that needs to be a new kernel-level option to limit the driver binding for a particular USB port. Not sure if it needs to be HCI-specific or can be implemented in a more generic way to work for any HCI type.
Oct 14 06:32:22 <DocScrutinizer05> oooh and we have no kernel hackers - at least no contracted ones
Oct 14 06:42:18 <DocScrutinizer05> linux kernel drivers, a never ending source of joy
Oct 14 06:52:47 <PaulFertser> Automatic driver binding for busses that support hot-plug is a feature that's probably present since earliest version. Probably windows used to behave differently but nowadays it does the same.
Oct 14 06:55:12 <DocScrutinizer05> then there must be an API doc for it
Oct 14 06:57:11 <DocScrutinizer05> wordt case we need to augment the USB controller driver to learn a "hardbind=<USBport>,<devicetype>" parameter or whatever
Oct 14 06:57:17 <DocScrutinizer05> worst*
Oct 14 06:58:16 <PaulFertser> And btw, given the complexity of protocols that are implemented by modern UMTS/LTE devices (QMI, MBIM, CDC Ethernet, CDC RNDIS) the attack surface might be pretty large, the protocols implementations you're going to use might want some serious security audit (code review, automatic fuzzing, etc)
Oct 14 06:59:29 <PaulFertser> Qubes OS tries to deal with threats like this by running dedicated VMs to handle dangerous devices.
Oct 14 07:00:26 <pabs3> btw what USB protocol is used between the modem and host? 
Oct 14 07:00:36 <DocScrutinizer05> not my business
Oct 14 07:01:33 <DocScrutinizer05> pabs3: you can use ttyUSB or a more sophisticated one
Oct 14 07:01:45 <DocScrutinizer05> iirc
Oct 14 07:05:17 <DocScrutinizer05> pabs3: http://www.seapraha.cz/download/
Oct 14 07:06:10 <DocScrutinizer05> http://www.seapraha.cz/download/20134826-phs8_driver.zip   http://www.seapraha.cz/download/22160944-PHS8_Linux_Driver_Postup_v1-00.txt
Oct 14 07:10:09 <PaulFertser> CDC-ECM it seems
Oct 14 07:10:41 <PaulFertser> And CDC-ACM for virtual ports.
Oct 14 07:11:08 <DocScrutinizer05> yeah
Oct 14 07:11:24 <PaulFertser> Hm, but those are handled by "usbserial" driver, not the regular cdc_acm.
Oct 14 07:11:31 <DocScrutinizer05> yes
Oct 14 07:12:06 <DocScrutinizer05> anyway there's no "special protocol"
Oct 14 07:12:21 <PaulFertser> I think pabs3's point here is that neo900 project being focused on security should really pay attention to this particular threat, so some work needs to be scheduled to mitigate it.
Oct 14 07:12:57 <DocScrutinizer05> we're developing hardware, not software
Oct 14 07:13:20 <PaulFertser> Both malicious reenumeration and malicious expoliting of bugs in cdc-ecm and usbserial needs to be covered.
Oct 14 07:13:33 <PaulFertser> But you can give hints to software devs and you'll be heard.
Oct 14 07:13:55 <DocScrutinizer05> I'm trying to do this, as far as my knowledge lasts
Oct 14 07:15:12 <DocScrutinizer05> I already forwarded all your highly appreciated comments and hints
Oct 14 07:15:23 <DocScrutinizer05> :-)
Oct 14 07:15:45 <pabs3> great :)
Oct 14 07:15:55 <pabs3> who is doing the software side btw?
Oct 14 07:16:20 <DocScrutinizer05> whoever wants. seems freemangordon and pali are very interested. see 
Oct 14 07:16:23 <DocScrutinizer05> ~fptf
Oct 14 07:16:24 <apt> fptf is, like, the Fremantle Porting Task Force, see http://talk.maemo.org/showthread.php?t=91308
Oct 14 07:17:17 <DocScrutinizer05> then hellekin and parazyd are just discussing this whole stuff on a larger scale with the above two, from a devuan POV, in #maemo-ssu
Oct 14 07:18:20 <DocScrutinizer05> http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2016-10-14.log.html
Oct 14 07:25:43 <pabs3> hmm, my laptop needs this USB whitelisting thing too. the camera is connected via USB
Oct 14 07:26:35 <pabs3> usbguard might be an option if this doesn't get implemented in Linux mainline
Oct 14 07:26:44 <DocScrutinizer05> yes, it's pretty disturbing that it's not more of an issue for generic USB stuff and linux, at large
Oct 14 07:29:05 <pabs3> it has been getting some attention due to Snowden and BadUSB and stuff
Oct 14 07:32:30 <DocScrutinizer05> http://mg.pov.lt/maemo-ssu-irclog/%23maemo-ssu.2016-10-14.log.html#t2016-10-14T10:26:36
Oct 14 07:32:33 <DocScrutinizer05> :-)
Oct 14 07:40:43 <DocScrutinizer05> /join #maemo-ssu
Oct 14 07:41:05 <DocScrutinizer05> it seems everybody meeting there to discuss this topic
Oct 14 09:38:29 <DocScrutinizer05> PaulFertser: http://www.linux-usb.org/usb.ids seems complete now. Let's see for how long
Oct 14 14:32:58 <DocScrutinizer05> pabs3: (email I forwarded) is rsync creating 'snapshots' as *.from files, and the disk is full on this server?
Oct 14 14:54:47 <DocScrutinizer05> sftp://joerg@openmoko.org/space/www/downloads.openmoko.org/developer/schematics/debugboards/OpenMoko_Debug_Board_V3__component-placement.pdf:from
Oct 14 14:54:56 <DocScrutinizer05> no idea what's that file
Oct 14 14:55:53 <DocScrutinizer05> can't look into it either, weird permissions/owner
Oct 14 15:07:29 <DocScrutinizer05> seems the move/consolidation from sita messed up some file ownerships (and permissions?)
Oct 15 01:58:15 <pabs3> DocScrutinizer05: deleted the unreadable files, they are all cruft
Oct 15 02:34:57 <DocScrutinizer05> thought as much. Thanks!
Oct 15 02:35:12 <DocScrutinizer05> did you have a look at the owner:group?
Oct 15 02:35:54 <DocScrutinizer05> owner=200 notknown
Oct 15 02:36:09 <DocScrutinizer05> group sth weird too
Oct 15 02:37:06 <DocScrutinizer05> I gather they got migrated from another host during consolidation and their owner numeric value been kept
Oct 15 02:37:37 <DocScrutinizer05> not that it matters too much
Oct 15 02:38:42 <DocScrutinizer05> pabs3: btw what struck my mind: would rsync obey .hidden/ files?
Oct 15 02:39:20 <pabs3> yeah, ownership is weird, maps to Debian-exim :)
Oct 15 02:39:41 <DocScrutinizer05> group, yes
Oct 15 02:39:53 <DocScrutinizer05> owner seems unknown numeric 200
Oct 15 02:40:22 <DocScrutinizer05> iirc
Oct 15 02:40:59 <pabs3> I don't think rsync treats .hidden files any differently
Oct 15 02:41:29 <DocScrutinizer05> that's what I thought. not a big issue but for sure not what I had in mind when I created hidden files
Oct 15 02:42:27 <DocScrutinizer05> now we at least know *how* that info leaked ;-P
Oct 15 02:43:15 <DocScrutinizer05> nevermind
Oct 15 02:43:29 <DocScrutinizer05> it's all perfectly fine
Oct 15 02:44:31 <pabs3> tested, it definitely transfers those
Oct 15 02:46:28 <DocScrutinizer05> nevermind, really. I just noticed it's not even .hidden but probably htaccess-handled or whatever
**** ENDING LOGGING AT Sat Oct 15 02:59:58 2016