-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Now this boolean controls sys_module, so we always transition but we
can turn off the ability to insert modules into the kernel.
This is much simpler then what we had before.
If you like this I have a similar patch for secure_mode_loadpolicy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5p9w0ACgkQrlYvE4MpobMcsgCeIu/qU3UgWNFw0cqiJJnziaS6
auUAnR7i9cIOrtDEbtZc546A6RN1Hohy
=QxNy
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: secure_mode_insmod.patch
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20110909/200af89b/attachment.pl
On 09/09/11 07:22, Daniel J Walsh wrote:
> Now this boolean controls sys_module, so we always transition but we
> can turn off the ability to insert modules into the kernel.
>
> This is much simpler then what we had before.
>
> If you like this I have a similar patch for secure_mode_loadpolicy
So with the current implementation, there are conditional module loaders and unconditional module loaders. Do we really want to make all module loading conditional? I'm fine with that, but are there reasons to keep the current conditional/unconditional behavior? If so we can still keep that functionality, but implement it similar to this patch.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/09/2011 11:56 AM, Christopher J. PeBenito wrote:
> On 09/09/11 07:22, Daniel J Walsh wrote:
>> Now this boolean controls sys_module, so we always transition but
>> we can turn off the ability to insert modules into the kernel.
>>
>> This is much simpler then what we had before.
>>
>> If you like this I have a similar patch for
>> secure_mode_loadpolicy
>
> So with the current implementation, there are conditional module
> loaders and unconditional module loaders. Do we really want to
> make all module loading conditional? I'm fine with that, but are
> there reasons to keep the current conditional/unconditional
> behavior? If so we can still keep that functionality, but
> implement it similar to this patch.
>
I think this should be unconditional. If you want to shutoff loading
kernel modules, this patch will do it even with unconfined programs
running. It would be a pain to run with this system, but at least the
users know that at a certain state of the machine no kernel modules
can be loaded.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5rM/YACgkQrlYvE4MpobNsbwCeJEp1ifXL0FRCb9VHEdjGR19u
UxEAn1w72gMHuca4LuzoyHcJQyYjSJ9F
=NXlE
-----END PGP SIGNATURE-----
On 09/10/11 05:55, Daniel J Walsh wrote:
> On 09/09/2011 11:56 AM, Christopher J. PeBenito wrote:
>> On 09/09/11 07:22, Daniel J Walsh wrote:
>>> Now this boolean controls sys_module, so we always transition but
>>> we can turn off the ability to insert modules into the kernel.
>>>
>>> This is much simpler then what we had before.
>>>
>>> If you like this I have a similar patch for
>>> secure_mode_loadpolicy
>
>> So with the current implementation, there are conditional module
>> loaders and unconditional module loaders. Do we really want to
>> make all module loading conditional? I'm fine with that, but are
>> there reasons to keep the current conditional/unconditional
>> behavior? If so we can still keep that functionality, but
>> implement it similar to this patch.
>
> I think this should be unconditional. If you want to shutoff loading
> kernel modules, this patch will do it even with unconfined programs
> running. It would be a pain to run with this system, but at least the
> users know that at a certain state of the machine no kernel modules
> can be loaded.
Then there is an issue with the patch. Currently unconfined domains have sys_module and its not controlled by the boolean. I'm fine with stripping this permission from unconfined domains.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/13/2011 01:17 PM, Christopher J. PeBenito wrote:
> On 09/10/11 05:55, Daniel J Walsh wrote:
>> On 09/09/2011 11:56 AM, Christopher J. PeBenito wrote:
>>> On 09/09/11 07:22, Daniel J Walsh wrote:
>>>> Now this boolean controls sys_module, so we always transition
>>>> but we can turn off the ability to insert modules into the
>>>> kernel.
>>>>
>>>> This is much simpler then what we had before.
>>>>
>>>> If you like this I have a similar patch for
>>>> secure_mode_loadpolicy
>>
>>> So with the current implementation, there are conditional
>>> module loaders and unconditional module loaders. Do we really
>>> want to make all module loading conditional? I'm fine with
>>> that, but are there reasons to keep the current
>>> conditional/unconditional behavior? If so we can still keep
>>> that functionality, but implement it similar to this patch.
>>
>> I think this should be unconditional. If you want to shutoff
>> loading kernel modules, this patch will do it even with
>> unconfined programs running. It would be a pain to run with this
>> system, but at least the users know that at a certain state of
>> the machine no kernel modules can be loaded.
>
> Then there is an issue with the patch. Currently unconfined
> domains have sys_module and its not controlled by the boolean. I'm
> fine with stripping this permission from unconfined domains.
>
I think it makes sense. If we have the boolean it should work for
targeted policy with or without the unconfined.pp installed.
We also have setup secure_mode_policyload like this in Fedora 16.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5vk+8ACgkQrlYvE4MpobNdZwCbBcoMH086q1JG3G6SfsRgfV9n
PNAAn32Z0JLg7pPocCVTJZWyK5Xjq6yk
=6lm+
-----END PGP SIGNATURE-----