USB authorization
Hello, I'm trying to find out whether FreeBSD has an equivalent to the USB (de)authorization interface that is implemented the Linux kernel [1], i.e. if there's a flag for each USB device and interface that controls whether that particular device/interface is allowed to communicate with the system. So far I haven't found anything promising so I guess there's no such interface. If that's true, do you think it would hard be to implement? Would it require refactoring of the USB subsystem or just a few lines at the right places and something to export this interface to the user space? Thanks! [1] https://www.kernel.org/doc/Documentation/usb/authorization.txt ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Trying to collect samples of USB descriptor data
Hello, I'm working on an open-source project called USBGuard (currently in the process of being packaged for Debian[1]) which aims to provide an user-space framework that complements the USB device authorization feature[2] in the Linux kernel. There are parts which deal with USB descriptor data and I would like to test them thoroughly (fuzzing, etc.). For that I need some samples of the USB descriptor data. I can generate some samples but it's always a good idea to have real world samples. Now to my actual request. I wrote a script[3] for collecting USB descriptor data from a Linux based system and I would like you to help me by running this script on your system (should work without root) and send me the results to dnk.usb...@gmail.com or by other means, whatever is convenient for you. The script is very simple and it should be easy to check that it doesn't do anything malicious. If you own some "exotic" USB devices, please connect them before running the script. Here's a short description of what the script does: 1. It looks for usb devices in /sys/bus/usb/devices 2. For each device it: - computes the sha1 of the USB descriptors (the "descriptors" file in the device sub-directory) - copies the "descriptors" file into a temporary directory - counts the number of configuration, interface and endpoint descriptors using lsusb and saves this information in the temporary directory 3. Compresses the temporary directory -- the archive is the result. 4. Removes the temporary directory [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825302 [2] https://www.kernel.org/doc/Documentation/usb/authorization.txt [3] https://raw.githubusercontent.com/dkopecek/usbguard/master/scripts/usb-descriptor-collect.sh Thank you!
Re: Trying to collect samples of USB descriptor data
Yes, that would be helpful. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Trying to collect samples of USB descriptor data
Hello, I'm working on an open-source project called USBGuard (Fedora package: https://admin.fedoraproject.org/pkgdb/package/rpms/usbguard/) which aims to provide an user-space framework that complements the USB device authorization feature[1] in the Linux kernel. There are parts which deal with USB descriptor data and I would like to test them thoroughly (fuzzing, etc.). For that I need some samples of the USB descriptor data. I can generate some samples but it's always a good idea to have real world samples. Now to my actual request. I wrote a script[2] for collecting USB descriptor data from a Linux based system and I would like you to help me by running this script on your system (should work without root) and send me the results to dnk.usb...@gmail.com or by other means, whatever is convenient for you. The script is very simple and it should be easy to check that it doesn't do anything malicious. Here's a short description of what the script does: 1. It looks for usb devices in /sys/bus/usb/devices 2. For each device it: - computes the sha1 of the USB descriptors (the "descriptors" file in the device sub-directory) - copies the "descriptors" file into a temporary directory - counts the number of configuration, interface and endpoint descriptors using lsusb and saves this information in the temporary directory 3. Compresses the temporary directory -- the archive is the result. 4. Removes the temporary directory [1] https://www.kernel.org/doc/Documentation/usb/authorization.txt [2] https://raw.githubusercontent.com/dkopecek/usbguard/master/scripts/usb-descriptor-collect.sh Thank you! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bug#791919: RFP: USBGuard -- protect your computer against rogue USB devices
Hello, On 05/22/2016 12:25 AM, Rebecca N. Palmer wrote: Control: merge -1 813809 I'd also like to see this (or an equivalent: I'm not aware of any, but haven't looked much) in Debian, and am willing to try packaging it, but am not sure whether it's a good idea for a non-DD, non-security-specialist to maintain a security tool. feel free to contact me if there are any issues with the upstream code w.r.t. packaging in Debian. I haven't packaged anything for Debian yet, so I won't be of much help in that area but I can try. It's in Fedora, with packaging [0] that looks fairly easy to translate to Debian (if that's legal - I don't know whether License: in a Fedora .spec means "including this packaging"); What is the legal problem here? I think the default license for the .spec file is MIT: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#License_of_Fedora_SPEC_Files The upstream repository (which includes the .spec file too) is licensed under GPLv2+. That's probably an inconsistency that I should fix... Regards, -- Daniel Kopeček Software Engineer, Special Projects Red Hat, Inc.
Bug#791919: RFP: USBGuard -- protect your computer against rogue USB devices
Hello, On 05/22/2016 12:25 AM, Rebecca N. Palmer wrote: Control: merge -1 813809 I'd also like to see this (or an equivalent: I'm not aware of any, but haven't looked much) in Debian, and am willing to try packaging it, but am not sure whether it's a good idea for a non-DD, non-security-specialist to maintain a security tool. feel free to contact me if there are any issues with the upstream code w.r.t. packaging in Debian. I haven't packaged anything for Debian yet, so I won't be of much help in that area but I can try. It's in Fedora, with packaging [0] that looks fairly easy to translate to Debian (if that's legal - I don't know whether License: in a Fedora .spec means "including this packaging"); What is the legal problem here? I think the default license for the .spec file is MIT: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#License_of_Fedora_SPEC_Files The upstream repository (which includes the .spec file too) is licensed under GPLv2+. That's probably an inconsistency that I should fix... Regards, -- Daniel Kopeček Software Engineer, Special Projects Red Hat, Inc.
Bug#791919: RFP: USBGuard -- protect your computer against rogue USB devices
Hello, On 05/22/2016 12:25 AM, Rebecca N. Palmer wrote: Control: merge -1 813809 I'd also like to see this (or an equivalent: I'm not aware of any, but haven't looked much) in Debian, and am willing to try packaging it, but am not sure whether it's a good idea for a non-DD, non-security-specialist to maintain a security tool. feel free to contact me if there are any issues with the upstream code w.r.t. packaging in Debian. I haven't packaged anything for Debian yet, so I won't be of much help in that area but I can try. It's in Fedora, with packaging [0] that looks fairly easy to translate to Debian (if that's legal - I don't know whether License: in a Fedora .spec means "including this packaging"); What is the legal problem here? I think the default license for the .spec file is MIT: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#License_of_Fedora_SPEC_Files The upstream repository (which includes the .spec file too) is licensed under GPLv2+. That's probably an inconsistency that I should fix... Regards, -- Daniel Kopeček Software Engineer, Special Projects Red Hat, Inc.
Re: [Open-scap] openscap does not collect the uuid property
Hello, On 05/10/2016 11:40 AM, Dragos Prisaca wrote: Hello Jan, I run oscap as root. Here are the steps to reproduce the issue: 1. Download the content from https://scap.nist.gov/validation/downloads/SCAP1.2ValidationTestContent_1-2.1.0.0.zip 2. # unzip SCAP1.2ValidationTestContent_1-2.1.0.0.zip 3. # unzip validationTestSuites_1-2.1.0.0.zip 4. # cd linux_partition_test/configuration_scripts/ 5. # dos2unix *.sh && chmod +x *.sh 6. # ./linux_partition_test_config1.sh 7. Run the linux_partition_test/linux_partition_test-datastream.xml with oscap 8. Open the scan results and look for a partition item with the following mount_point: /mnt/my_loop_device /dev/loop3 The "not collected" status is set by the probe if the library/probes were compiled without blkid support: https://github.com/OpenSCAP/openscap/blob/maint-1.2/src/OVAL/probes/unix/linux/partition.c#L232 Regards, -- Daniel Kopeček Software Engineer, Special Projects Red Hat, Inc. ___ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list
[frameworks-solid] [Bug 347463] Authorize newly connected USB devices
https://bugs.kde.org/show_bug.cgi?id=347463 --- Comment #2 from Daniel Kopeček <dkope...@redhat.com> --- Hello, recently, I've implemented a D-Bus interface in USBGuard. That should make the integration with it much easier for various desktop apps/environments. The interface is not set in stone yet, so if you are going to consider USBGuard to resolve this RFE and find out that the current interface has some design flaws, then I can implement additional features and make changes to it. -- You are receiving this mail because: You are watching all bug changes.
