Bug 481618 - SELinux policy stops me being able to connect my phone to my netbook via bluetooth
SELinux policy stops me being able to connect my phone to my netbook via blue...
Status: CLOSED DUPLICATE of bug 520728
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: SELinux
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-26 13:43 EST by Alex Bennee
Modified: 2009-09-16 11:35 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-16 11:35:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
SELinux report (5.08 KB, text/plain)
2009-01-26 13:43 EST, Alex Bennee
no flags Details

  None (edit)
Description Alex Bennee 2009-01-26 13:43:43 EST
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
Comment 1 Daniel Walsh 2009-01-26 13:57:08 EST
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?
Comment 2 Bastien Nocera 2009-04-23 14:10:28 EDT
(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?
Comment 3 Daniel Walsh 2009-04-23 17:36:48 EDT
Can you do it in the init script?  Can HAL or someone else do it.
Comment 4 Bastien Nocera 2009-04-23 19:28:08 EDT
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).
Comment 5 Alex Bennee 2009-04-24 05:05:02 EDT
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.
Comment 6 Daniel Walsh 2009-04-24 06:46:20 EDT
Are the modules all located in the same directory?  I don't think we can control what objects can be loaded into the kernel.
Comment 7 Bastien Nocera 2009-04-29 06:14:57 EDT
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
Comment 8 Daniel Walsh 2009-04-29 09:41:44 EDT
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?
Comment 9 Stephen Smalley 2009-04-29 10:34:45 EDT
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?
Comment 10 Stephen Smalley 2009-04-29 10:45:14 EDT
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.
Comment 11 Daniel Walsh 2009-04-29 10:49:45 EDT
Fixing the kernel would make me happier.
Comment 12 Alex Bennee 2009-09-08 17:27:08 EDT
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?
Comment 13 Eric Paris 2009-09-08 17:32:36 EDT
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.....
Comment 14 Bastien Nocera 2009-09-16 10:14:24 EDT
Moving to the kernel as per last comment.
Comment 15 Eric Paris 2009-09-16 11:35:58 EDT

*** This bug has been marked as a duplicate of bug 520728 ***

Note You need to log in before you can comment on or make changes to this bug.