Created attachment 330019 [details] SELinux report Description of problem: I can't connect my mobile to my netbook via bluetooth How reproducible: Every time Steps to Reproduce: 1. Pair phone with netbook 2. On phone, Select My Devices, My Netbook, Connect Actual results: SELinux pops up warning of policy error. Log attached Expected results: I can run bnep based network between the two devices Additional info: Phone is Sony Ericson K800i
Miroslav, you can add kernel_read_network_state(bluetooth_t) The Bluetooth should not be loading kernel modules on demand. Allowing a daemon to modify the running kernel is not something we want to allow. Is there any other way we can get this to happen?
(In reply to comment #1) > Miroslav, you can add kernel_read_network_state(bluetooth_t) > > The Bluetooth should not be loading kernel modules on demand. Allowing a > daemon to modify the running kernel is not something we want to allow. And how do we get the bnep module loaded then? > Is > there any other way we can get this to happen?
Can you do it in the init script? Can HAL or someone else do it.
bnep isn't used by the majority of people. This is why it's loaded when needed (eg. when you want to communicate with a device that uses the BNEP protocol).
Is it not possible to restrict the daemon to only being able to load the bnep module or does that still present a security hole? I agree that always loading the module would be undesirable. To be honest I wish Fedora would leave most of the bluetooth stack unloaded and the hardware quiet until I actually wanted to use it. But that's a side issue.
Are the modules all located in the same directory? I don't think we can control what objects can be loaded into the kernel.
The module lives in: /lib/modules/`uname -r`/kernel/net/bluetooth/bnep/ This module might also be loaded on-the-fly: /lib/modules/`uname -r`/kernel/net/bluetooth/cmtp/cmtp.ko
So we could build a solution that allowed bluetooth to fork/exec insmod or modprobe to allow them to load the kernel module. Then I could write an SELinux policy that would transition from bluetooth_t -> insmod_exec_t -> bluetooth_insmod_t Which can load load kernel modules but can only read kernel modules labeled bluetooth_modules_object_t and no other kernel modules. Anyone have a better solution?
I think this may be a kernel issue. If you look at the syscall audit record, you'll see that the sys_module denial occurred on an ioctl() system call. Looking around, I see that net/core/dev.c:dev_ioctl() will call dev_load(), which will look up the driver name for the interface, check that the _current_ process has CAP_SYS_MODULE, and then invoke request_module() on it. request_module() itself will ultimately be serviced by a kernel thread and thus doesn't require bluetooth to have these permissions at all, but we are getting caught on the check prior to calling request_module(). I don't quite follow the reasoning for imposing CAP_SYS_MODULE in dev_load() when there are lots of other ways to trigger the kernel module loader from userspace that are not gated by CAP_SYS_MODULE checks. Eric?
This appears to be the same issue as bug 241401. There the decision seems to have been to allow sys_module to ip. However, this is more permissive than required/desired - allowing sys_module to the userspace context means that it can directly load arbitrary modules itself, whereas here the kernel is initiating the actual load and doing it via upcall to modprobe.
Fixing the kernel would make me happier.
Just chasing up the status on this. Was the conclusion this is a kernel problem or an SELinux problem? If it's a kernel problem has a bug been raised in the kernel bugzilla?
it's a kernel problem. It will not be changed upstream until 2.6.32. I will backport the changes to f12 in the next couple days. I'm not certain what we want to do for F10 and F11.....
Moving to the kernel as per last comment.
*** This bug has been marked as a duplicate of bug 520728 ***