On Fri, Oct 11, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > > Like I said before, gphoto, sane, etc, don't have security policies. > > That's the systems job, not the applications. > > > > /sbin/hotplug, being part of the system, should solve this. > > And like I said, being part of the system, its job is to > *FOLLOW* policies. The _only_ policy it has any business > defining is "default-secure". Just look at all the trouble > MSFT causes by choosing "default-unprotected"!!
No, the kernel does default-secure via devmode=. > Perhaps one missing piece here is the observation that security > policies should be controlled by a person, likely by whoever owns > the hardware. They're not part of the OS or the application. Sure and they control that by configuring hotplug. However, hotplug is more certainly part of the OS and as a result, is what defines the the security policy. That may changed by the user, but most certainly not by the application. > Though it's worth pointing out that bundling a scanner app with > an OS makes a lot of those distinctions moot. The whole bundle > needs to be default-secure. Installing an app component into a > place like /usr/bin is effectively making it part of the OS, just > like installing a different component into /etc/hotplug/usb does. It's not really moot, it just blurs things a little. While I don't care if the official hotplug tarball makes it default-secure, it's the users choice, or the distributions choice, to change it to something dumber (read/write for everybody!) or smarter (read/write for people on the console). Security policy is the job of the OS, not the application. While the application is many times marketed as part of the OS, for the purposes of this discussion, it isn't. It's just another piece of random code that wants to talk to devices. > > gphoto and sane have no business telling everyone how to manage > > privileges. > > Actually they have every business documenting requirements and > providing tools that make it easy to satisfy those on stock > (default-secure!) systems. That's exactly what they did, last > time I checked. They have no requirements. They are at the whim of the OS defined security policy. If they are to work like the user expects it to, the OS sets up the permissions correctly. But the job is absolutely up to ths OS and in the case of Linux that usually means the distribution. > One end-user front end to the security policy is always the > application anyway ... that's where a "no, you can't use the > bedroom-cam just now" policy eventually materializes in a way > that some user (FBI etc) will see. But it configures the OS. You need to keep security as low level as possible to avoid any loopholes. Anyway, this points back to that hotplug needs to make this easy. Right now, there is nothing in the standard hotplug userspace that makes this easy for anyone. It encourages applications to do the hideous thing and do whatever they think is best. We should provide some sort of standard support where an application can install a configuration of what devices it can support and the OS does the rest. This is the chance to set a standard. The obvious parallel here is that programs like minicom don't change the permissions of /dev/ttyS0. It's the job of the OS to set it up. It just so happens that most distributions set it to something that's reasonable at install. JE ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
