All of lore.kernel.org
 help / color / mirror / Atom feed
From: dwalsh@redhat.com (Daniel J Walsh)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] udev and secure_mode_insmod in selinux-policy-3.9.7-10.fc14 and later
Date: Fri, 07 Jan 2011 10:22:51 -0500	[thread overview]
Message-ID: <4D272FCB.7010301@redhat.com> (raw)
In-Reply-To: <4D26637F.9090503@catseye.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/06/2011 07:51 PM, Mark Montague wrote:
> Under selinux-policy-3.9.7-7.fc14 and previous, udev was able to load 
> kernel modules even when secure_mode_insmod=on  Starting with the next 
> policy release, 3.9.7-10.fc14, this fails, resulting in the ethernet 
> device not being configured when the system boots; no denial is logged.
> 
> Setting secure_mode_insmod=off and rebooting results in a working 
> system, but allows other restricted domains to load kernel modules -- 
> which is a shame since I also have unconfined_login=off and 
> secure_mode=on.  So I added a local module with the following rule in 
> order to get the 3.9.7-7.fc14 behavior with secure_mode_insmod=on.  (The 
> seemingly superfluous enclosing "if" is needed to avoid a duplicate rule 
> error).
> 
>      if (secure_mode_insmod) {
>          modutils_domtrans_insmod_uncond(udev_t)
>      }
> 
> My question is:  what is the desired behavior for future policy 
> releases?  Should secure_mode_insmod=on affect udev as it currently does 
> under 3.9.7-10.fc14 and later?  (A literal reading of the description 
> for this boolean implies it should).  Or should a new boolean be added 
> (off by default) to allow administrators to have udev load kernel 
> modules even when secure_mode_insmod=on?  Or something else?
> 
> Apologies if this is actually a non-issue due to lack of understanding 
> on my end (but any education would be welcome in that case!)
> 
> --
>    Mark Montague
>    mark at catseye.org
> 
> --
> selinux mailing list
> selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
> 
> 
Lets ask this on refpolicy list, to see if we can get consensus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0nL8sACgkQrlYvE4MpobOqdgCdG4Vn8hVcg+qDSp3qPCp9gcpi
ikMAnjZzQU+F9xaqBB7ujZcdWpt+STsp
=M2Xx
-----END PGP SIGNATURE-----

           reply	other threads:[~2011-01-07 15:22 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <4D26637F.9090503@catseye.org>]

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=4D272FCB.7010301@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.