From: dwalsh@redhat.com (Daniel J Walsh)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] In Fedora policy we have simplified the secure_mode_insmod
Date: Tue, 13 Sep 2011 13:33:35 -0400 [thread overview]
Message-ID: <4E6F93EF.90904@redhat.com> (raw)
In-Reply-To: <4E6F902F.8040407@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-----
prev parent reply other threads:[~2011-09-13 17:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-09 11:22 [refpolicy] In Fedora policy we have simplified the secure_mode_insmod Daniel J Walsh
2011-09-09 15:56 ` Christopher J. PeBenito
2011-09-10 9:55 ` Daniel J Walsh
2011-09-13 17:17 ` Christopher J. PeBenito
2011-09-13 17:33 ` Daniel J Walsh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E6F93EF.90904@redhat.com \
--to=dwalsh@redhat.com \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.