attached is dmesg of the latest
Head giving me an avc denial that
is giving me an error with checkpolicy:
/usr/bin/checkpolicy -c 22 -U deny policy.conf -o policy.22
/usr/bin/checkpolicy: loading policy configuration from policy.conf
policy/modules/services/xserver.te":1138:ERROR 'permission
module_request is not defined for class system' at token ';' on line
2904222:
allow NetworkManager_t kernel_t:system module_request;
#============= NetworkManager_t ==============
policy/modules/services/xserver.te":1141:ERROR 'permission
module_request is not defined for class system' at token ';' on line
2904225:
#============= insmod_t ==============
allow insmod_t kernel_t:system module_request;
policy/modules/services/xserver.te":1144:ERROR 'permission
module_request is not defined for class system' at token ';' on line
2904228:
allow iptables_t kernel_t:system module_request;
#============= iptables_t ==============
checkpolicy: error(s) encountered while parsing configuration
make: *** [policy.22] Error 1
(please ignore the xserver.te, as a quick way using a monolithic
policy, I just randomly throw the allow rules anywhere, before
individually locating the right location).
here is what git bisect is showing me:
25354c4fee169710fd9da15f3bb2abaa24dcf933 is first bad commit
commit 25354c4fee169710fd9da15f3bb2abaa24dcf933
Author: Eric Paris <[email protected]>
Date: Thu Aug 13 09:45:03 2009 -0400
SELinux: add selinux_kernel_module_request
This patch adds a new selinux hook so SELinux can arbitrate if a given
process should be allowed to trigger a request for the kernel to try to
load a module. This is a different operation than a process trying to load
a module itself, which is already protected by CAP_SYS_MODULE.
Signed-off-by: Eric Paris <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Signed-off-by: James Morris <[email protected]>
:040000 040000 0585d8667e7c54b9b3e07f419dc8eff62b32fe96
f63f56f137352a90a909d11d37e8f5462f4306ff M security
and FWIW git bisect log:
git bisect start
# bad: [332a3392188e0ad966543c87b8da2b9d246f301d] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
git bisect bad 332a3392188e0ad966543c87b8da2b9d246f301d
# good: [ed680c4ad478d0fee9740f7d029087f181346564] Linux 2.6.31-rc5
git bisect good ed680c4ad478d0fee9740f7d029087f181346564
# good: [f415c413f458837bd0c27086b79aca889f9435e4] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
git bisect good f415c413f458837bd0c27086b79aca889f9435e4
# good: [6a0f4021469727675b83d85ac91d106bfae0e2c3] Merge branch
'topic/dummy' into for-linus
git bisect good 6a0f4021469727675b83d85ac91d106bfae0e2c3
# bad: [a12e4d304ce701844c639541d90df86e165d03f9] Merge branch
'writeback' of git://git.kernel.dk/linux-2.6-block
git bisect bad a12e4d304ce701844c639541d90df86e165d03f9
# bad: [2490138cb785d299d898b579fa2874a59a3d321a] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
git bisect bad 2490138cb785d299d898b579fa2874a59a3d321a
# bad: [9f0ab4a3f0fdb1ff404d150618ace2fa069bb2e1] binfmt_elf: fix
PT_INTERP bss handling
git bisect bad 9f0ab4a3f0fdb1ff404d150618ace2fa069bb2e1
# good: [896a6de40ef3814525632609799af909338f50c3] mm_for_maps: take
->cred_guard_mutex to fix the race with exec
git bisect good 896a6de40ef3814525632609799af909338f50c3
# bad: [0c2c9a3fc77e8b60d43d9bd2ca46eb4dddb0ff76] KEYS: Allow
keyctl_revoke() on keys that have SETATTR but not WRITE perm [try #6]
git bisect bad 0c2c9a3fc77e8b60d43d9bd2ca46eb4dddb0ff76
# bad: [ece13879e74313e62109e0755dd3d4f172df89e2] Merge branch
'master' into next
git bisect bad ece13879e74313e62109e0755dd3d4f172df89e2
# bad: [25354c4fee169710fd9da15f3bb2abaa24dcf933] SELinux: add
selinux_kernel_module_request
git bisect bad 25354c4fee169710fd9da15f3bb2abaa24dcf933
# good: [a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c] Networking: use
CAP_NET_ADMIN when deciding to call request_module
git bisect good a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c
# good: [9188499cdb117d86a1ea6b04374095b098d56936] security:
introducing security_request_module
git bisect good 9188499cdb117d86a1ea6b04374095b098d56936
The system is an LFS,
there is no proprietary modules
at all with this kernel.
I have another machine running
rc-8 and it seems to not be producing
this avc.(keep in mind it does have
two proprietary modules: nvidia wl).
--
Justin P. Mattock
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg
Type: application/octet-stream
Size: 52104 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20090912/4a835a73/attachment-0001.obj
On Sat, 2009-09-12 at 15:09 -0700, Justin Mattock wrote:
> attached is dmesg of the latest
> Head giving me an avc denial that
> is giving me an error with checkpolicy:
>
> /usr/bin/checkpolicy -c 22 -U deny policy.conf -o policy.22
> /usr/bin/checkpolicy: loading policy configuration from policy.conf
> policy/modules/services/xserver.te":1138:ERROR 'permission
> module_request is not defined for class system' at token ';' on line
> 2904222:
> allow NetworkManager_t kernel_t:system module_request;
> #============= NetworkManager_t ==============
> policy/modules/services/xserver.te":1141:ERROR 'permission
> module_request is not defined for class system' at token ';' on line
> 2904225:
> #============= insmod_t ==============
> allow insmod_t kernel_t:system module_request;
> policy/modules/services/xserver.te":1144:ERROR 'permission
> module_request is not defined for class system' at token ';' on line
It's because you are using the -U deny. You are telling the kernel to
deny unknown permissions and then you are trying to define an unknown
permission. There is nothing wrong with the kernel.
I do need to submit the policy path to define it, but that's not a good
idea until we know more or all of the places it is needed. I hoped to
work on that with dwalsh in rawhide before we push the policy patch
upstream. You can help there! In your base policy module you need to
define 'request_module' in the system class in
policy/flash/access_vectors rebuild and load the base policy policy
module. Then you can use the request_module permission.
-Eric
On Sat, Sep 12, 2009 at 3:28 PM, Eric Paris <[email protected]> wrote:
> On Sat, 2009-09-12 at 15:09 -0700, Justin Mattock wrote:
>> attached is dmesg of the latest
>> Head giving me an avc denial that
>> is giving me an error with checkpolicy:
>>
>> /usr/bin/checkpolicy -c 22 ?-U deny policy.conf -o policy.22
>> /usr/bin/checkpolicy: ?loading policy configuration from policy.conf
>> policy/modules/services/xserver.te":1138:ERROR 'permission
>> module_request is not defined for class system' at token ';' on line
>> 2904222:
>> allow NetworkManager_t kernel_t:system module_request;
>> #============= NetworkManager_t ==============
>> policy/modules/services/xserver.te":1141:ERROR 'permission
>> module_request is not defined for class system' at token ';' on line
>> 2904225:
>> #============= insmod_t ==============
>> allow insmod_t kernel_t:system module_request;
>> policy/modules/services/xserver.te":1144:ERROR 'permission
>> module_request is not defined for class system' at token ';' on line
>
> It's because you are using the -U deny. ?You are telling the kernel to
> deny unknown permissions and then you are trying to define an unknown
> permission. ?There is nothing wrong with the kernel.
>
> I do need to submit the policy path to define it, but that's not a good
> idea until we know more or all of the places it is needed. ?I hoped to
> work on that with dwalsh in rawhide before we push the policy patch
> upstream. ?You can help there! ?In your base policy module you need to
> define 'request_module' in the system class in
> policy/flash/access_vectors rebuild and load the base policy policy
> module. ?Then you can use the request_module permission.
>
> -Eric
>
>
Cool,
I can try and see if I can create
a class for the policy(good learning here)
but just keep in mind, don't wait up for me,
for it could take a while.
Anyways I went in and commented out the
unknown permissions option in build.conf(then
make clean make conf etc..) and
it seems to keep triggering this error.
>From what it seems, maybe I have something
wrong with my userspace tools.
(ill update tomorrow, and see if it compiles
through).
--
Justin P. Mattock
On Sat, 2009-09-12 at 16:06 -0700, Justin Mattock wrote:
> On Sat, Sep 12, 2009 at 3:28 PM, Eric Paris <[email protected]> wrote:
> > On Sat, 2009-09-12 at 15:09 -0700, Justin Mattock wrote:
> >> attached is dmesg of the latest
> >> Head giving me an avc denial that
> >> is giving me an error with checkpolicy:
> >>
> >> /usr/bin/checkpolicy -c 22 -U deny policy.conf -o policy.22
> >> /usr/bin/checkpolicy: loading policy configuration from policy.conf
> >> policy/modules/services/xserver.te":1138:ERROR 'permission
> >> module_request is not defined for class system' at token ';' on line
> >> 2904222:
> >> allow NetworkManager_t kernel_t:system module_request;
> >> #============= NetworkManager_t ==============
> >> policy/modules/services/xserver.te":1141:ERROR 'permission
> >> module_request is not defined for class system' at token ';' on line
> >> 2904225:
> >> #============= insmod_t ==============
> >> allow insmod_t kernel_t:system module_request;
> >> policy/modules/services/xserver.te":1144:ERROR 'permission
> >> module_request is not defined for class system' at token ';' on line
> >
> > It's because you are using the -U deny. You are telling the kernel to
> > deny unknown permissions and then you are trying to define an unknown
> > permission. There is nothing wrong with the kernel.
> >
> > I do need to submit the policy path to define it, but that's not a good
> > idea until we know more or all of the places it is needed. I hoped to
> > work on that with dwalsh in rawhide before we push the policy patch
> > upstream. You can help there! In your base policy module you need to
> > define 'request_module' in the system class in
> > policy/flash/access_vectors rebuild and load the base policy policy
> > module. Then you can use the request_module permission.
> >
> > -Eric
> >
> >
>
> Cool,
> I can try and see if I can create
> a class for the policy(good learning here)
> but just keep in mind, don't wait up for me,
> for it could take a while.
>
> Anyways I went in and commented out the
> unknown permissions option in build.conf(then
> make clean make conf etc..) and
> it seems to keep triggering this error.
>
> From what it seems, maybe I have something
> wrong with my userspace tools.
> (ill update tomorrow, and see if it compiles
> through).
Ah no, sorry, I wasn't clear. The -U dney is what causes the kernel to
audit the denial. Without that the kernel won't complain and will work
just fine without those rules. With the deny you are going to have to
add the one line to the file I indicated and include those rules.
Thanks
-Eric
On Sat, Sep 12, 2009 at 3:28 PM, Eric Paris <[email protected]> wrote:
> On Sat, 2009-09-12 at 15:09 -0700, Justin Mattock wrote:
>> attached is dmesg of the latest
>> Head giving me an avc denial that
>> is giving me an error with checkpolicy:
>>
>> /usr/bin/checkpolicy -c 22 ?-U deny policy.conf -o policy.22
>> /usr/bin/checkpolicy: ?loading policy configuration from policy.conf
>> policy/modules/services/xserver.te":1138:ERROR 'permission
>> module_request is not defined for class system' at token ';' on line
>> 2904222:
>> allow NetworkManager_t kernel_t:system module_request;
>> #============= NetworkManager_t ==============
>> policy/modules/services/xserver.te":1141:ERROR 'permission
>> module_request is not defined for class system' at token ';' on line
>> 2904225:
>> #============= insmod_t ==============
>> allow insmod_t kernel_t:system module_request;
>> policy/modules/services/xserver.te":1144:ERROR 'permission
>> module_request is not defined for class system' at token ';' on line
>
> It's because you are using the -U deny. ?You are telling the kernel to
> deny unknown permissions and then you are trying to define an unknown
> permission. ?There is nothing wrong with the kernel.
>
> I do need to submit the policy path to define it, but that's not a good
> idea until we know more or all of the places it is needed. ?I hoped to
> work on that with dwalsh in rawhide before we push the policy patch
> upstream. ?You can help there! ?In your base policy module you need to
> define 'request_module' in the system class in
> policy/flash/access_vectors rebuild and load the base policy policy
> module. ?Then you can use the request_module permission.
>
> -Eric
>
>
O.K. this was just a hit and a miss
(I don't know what I'm doing but am willing to try)
below fixes the error from checkpolicy,
but I'm not sure if it's correct.
>From 4095a245f8a4a75d8ab2f94d816159d8b180ed1f Mon Sep 17 00:00:00 2001
From: Justin P. Mattock <[email protected]>
Date: Sat, 12 Sep 2009 16:42:06 -0700
Subject: [PATCH] add module_request support
Signed-off-by: Justin P. Mattock <[email protected]>
---
policy/flask/access_vectors | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors
index 3998b77..67ab292 100644
--- a/policy/flask/access_vectors
+++ b/policy/flask/access_vectors
@@ -349,6 +349,7 @@ class system
syslog_read
syslog_mod
syslog_console
+ module_request
}
#
--
1.6.3.2
--
Justin P. Mattock
On Sat, 2009-09-12 at 16:46 -0700, Justin Mattock wrote:
> On Sat, Sep 12, 2009 at 3:28 PM, Eric Paris <[email protected]> wrote:
> > On Sat, 2009-09-12 at 15:09 -0700, Justin Mattock wrote:
> >> attached is dmesg of the latest
> >> Head giving me an avc denial that
> >> is giving me an error with checkpolicy:
> >>
> >> /usr/bin/checkpolicy -c 22 -U deny policy.conf -o policy.22
> >> /usr/bin/checkpolicy: loading policy configuration from policy.conf
> >> policy/modules/services/xserver.te":1138:ERROR 'permission
> >> module_request is not defined for class system' at token ';' on line
> >> 2904222:
> >> allow NetworkManager_t kernel_t:system module_request;
> >> #============= NetworkManager_t ==============
> >> policy/modules/services/xserver.te":1141:ERROR 'permission
> >> module_request is not defined for class system' at token ';' on line
> >> 2904225:
> >> #============= insmod_t ==============
> >> allow insmod_t kernel_t:system module_request;
> >> policy/modules/services/xserver.te":1144:ERROR 'permission
> >> module_request is not defined for class system' at token ';' on line
> >
> > It's because you are using the -U deny. You are telling the kernel to
> > deny unknown permissions and then you are trying to define an unknown
> > permission. There is nothing wrong with the kernel.
> >
> > I do need to submit the policy path to define it, but that's not a good
> > idea until we know more or all of the places it is needed. I hoped to
> > work on that with dwalsh in rawhide before we push the policy patch
> > upstream. You can help there! In your base policy module you need to
> > define 'request_module' in the system class in
> > policy/flash/access_vectors rebuild and load the base policy policy
> > module. Then you can use the request_module permission.
> >
> > -Eric
> >
> >
>
> O.K. this was just a hit and a miss
> (I don't know what I'm doing but am willing to try)
> below fixes the error from checkpolicy,
> but I'm not sure if it's correct.
>
>
> From 4095a245f8a4a75d8ab2f94d816159d8b180ed1f Mon Sep 17 00:00:00 2001
> From: Justin P. Mattock <[email protected]>
> Date: Sat, 12 Sep 2009 16:42:06 -0700
> Subject: [PATCH] add module_request support
>
> Signed-off-by: Justin P. Mattock <[email protected]>
> ---
> policy/flask/access_vectors | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors
> index 3998b77..67ab292 100644
> --- a/policy/flask/access_vectors
> +++ b/policy/flask/access_vectors
> @@ -349,6 +349,7 @@ class system
> syslog_read
> syslog_mod
> syslog_console
> + module_request
> }
Yes that is correct (outside of the fact you used eight spaces instead
of a tab)
But upstream should not commit this until a number of people have tried
to run kernels with it defined and flushed out some reasonable number of
the necessary allow rules (because just defining it will cause people
with -U allow to start getting denials).
-Eric
Eric Paris wrote:
> On Sat, 2009-09-12 at 16:46 -0700, Justin Mattock wrote:
>
>> On Sat, Sep 12, 2009 at 3:28 PM, Eric Paris<[email protected]> wrote:
>>
>>> On Sat, 2009-09-12 at 15:09 -0700, Justin Mattock wrote:
>>>
>>>> attached is dmesg of the latest
>>>> Head giving me an avc denial that
>>>> is giving me an error with checkpolicy:
>>>>
>>>> /usr/bin/checkpolicy -c 22 -U deny policy.conf -o policy.22
>>>> /usr/bin/checkpolicy: loading policy configuration from policy.conf
>>>> policy/modules/services/xserver.te":1138:ERROR 'permission
>>>> module_request is not defined for class system' at token ';' on line
>>>> 2904222:
>>>> allow NetworkManager_t kernel_t:system module_request;
>>>> #============= NetworkManager_t ==============
>>>> policy/modules/services/xserver.te":1141:ERROR 'permission
>>>> module_request is not defined for class system' at token ';' on line
>>>> 2904225:
>>>> #============= insmod_t ==============
>>>> allow insmod_t kernel_t:system module_request;
>>>> policy/modules/services/xserver.te":1144:ERROR 'permission
>>>> module_request is not defined for class system' at token ';' on line
>>>>
>>> It's because you are using the -U deny. You are telling the kernel to
>>> deny unknown permissions and then you are trying to define an unknown
>>> permission. There is nothing wrong with the kernel.
>>>
>>> I do need to submit the policy path to define it, but that's not a good
>>> idea until we know more or all of the places it is needed. I hoped to
>>> work on that with dwalsh in rawhide before we push the policy patch
>>> upstream. You can help there! In your base policy module you need to
>>> define 'request_module' in the system class in
>>> policy/flash/access_vectors rebuild and load the base policy policy
>>> module. Then you can use the request_module permission.
>>>
>>> -Eric
>>>
>>>
>>>
>> O.K. this was just a hit and a miss
>> (I don't know what I'm doing but am willing to try)
>> below fixes the error from checkpolicy,
>> but I'm not sure if it's correct.
>>
>>
>> From 4095a245f8a4a75d8ab2f94d816159d8b180ed1f Mon Sep 17 00:00:00 2001
>> From: Justin P. Mattock<[email protected]>
>> Date: Sat, 12 Sep 2009 16:42:06 -0700
>> Subject: [PATCH] add module_request support
>>
>> Signed-off-by: Justin P. Mattock<[email protected]>
>> ---
>> policy/flask/access_vectors | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors
>> index 3998b77..67ab292 100644
>> --- a/policy/flask/access_vectors
>> +++ b/policy/flask/access_vectors
>> @@ -349,6 +349,7 @@ class system
>> syslog_read
>> syslog_mod
>> syslog_console
>> + module_request
>> }
>>
>
>
> Yes that is correct (outside of the fact you used eight spaces instead
> of a tab)
>
> But upstream should not commit this until a number of people have tried
> to run kernels with it defined and flushed out some reasonable number of
> the necessary allow rules (because just defining it will cause people
> with -U allow to start getting denials).
>
> -Eric
>
>
>
Hey alright.(id have to say a lucky
guess on my part).
In this case either you can take the
patch(If I need to redu it I will)
sign off on it, then store it somewhere
until people start hitting this
then go from there.
As a backup I'll leave it on my facebook
account(so I don't forget and loose it).
Overall Thanks for helping me on this.
Justin P. Mattock