what is the point of semodule -u?

what is the point of semodule -u?

[Russell Coker]

semodule supports options "-i" for install and "-u" for upgrade.  It seems 
that "semodule -i" will upgrade a module, so what is the point 
of "semodule -u"?  Are we assuming that a user or script that calls semodule 
doesn't know what it is doing and relies on the "-u" option refusing to 
install the same (or an older) version for correct results?

If so then I doubt that it will work well as I don't think that versions can 
be tracked accurately with the way the code is developed (EG a new release 
from a distribution vendor might have a higher version number than your local 
customisation even though your local changes are more relevant for your 
environment).

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: what is the point of semodule -u?

[Stephen Smalley]

On Wed, 2008-07-23 at 10:17 +1000, Russell Coker wrote:
> semodule supports options "-i" for install and "-u" for upgrade.  It seems 
> that "semodule -i" will upgrade a module, so what is the point 
> of "semodule -u"?  Are we assuming that a user or script that calls semodule 
> doesn't know what it is doing and relies on the "-u" option refusing to 
> install the same (or an older) version for correct results?
> 
> If so then I doubt that it will work well as I don't think that versions can 
> be tracked accurately with the way the code is developed (EG a new release 
> from a distribution vendor might have a higher version number than your local 
> customisation even though your local changes are more relevant for your 
> environment).

I'm not entirely sure about the original rationale for it, but upgrade
appears to differ from install in two ways:
1) It will fail if a module of the same name isn't already installed
(vs. adding it), and
2) It will fail if a module with the same name and the same or higher
version number is installed already (vs. replacing it).

So for example if you ran semodule -u *.pp on some directory full of .pp
files, it would only actually install modules that already had prior
versions of the same module installed and that were newer in version
number.

Not sure if that is practically useful or not.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: what is the point of semodule -u?

[Russell Coker]

On Wednesday 23 July 2008 12:11, Stephen Smalley <stephen.smalley@gmail.com> 
wrote:
> So for example if you ran semodule -u *.pp on some directory full of .pp
> files, it would only actually install modules that already had prior
> versions of the same module installed and that were newer in version
> number.

Have you found it to work like that?

I tested on Debian/Etch and CentOS 5.2 and found that it would abort on the 
first error.

Of course you could do:
for n in *.pp ; semodule -u $n ; done

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Policy loading: initramfs vs. patched /sbin/init

[Stephen Smalley]

Hi,

I saw your blog entry about policy loading on planet selinux - you ought
to bring issues like that up on selinux list for discussion rather than
just blogging about them.

First, to clarify, while Ubuntu and Fedora are initiating the policy
load from the initramfs, they are taking the policy from the real root
filesystem.  Thus, the policy is not being stored on the initramfs image
and updates to policy do not require rebuilding the image.

Both Ubuntu and Fedora have the script that runs from the initramfs
initiate the policy load, but Ubuntu does it by having the script invoke
the load_policy utility from the real root (chroot /path/to/realroot
load_policy -i) while Fedora does it by having the script invoke a nash
built-in command that directly calls the selinux_init_load_policy()
libselinux function call after chroot'ing into the real root.  The
Fedora approach was motivated by not wanting to pull the chroot utility
into the initrd and by wanting more precise error handling (making nash
exit if policy load fails and the system is enforcing so that the system
halts).  However this has caused some issues with pulling libsepol into
the initramfs and thereby limiting the maximum policy that can be loaded
to whatever policy version is supported by the initramfs libsepol.

On the positive side, the initramfs-based approach does mean
that /sbin/init from the real root automatically transitions into the
right domain since policy is already loaded.  And policy gets loaded no
matter what init is used or even if the user specifies an alternate
init= program on the kernel command line.

As you note, performing the load from initramfs can be problematic for
systems that cannot or choose not to use an initramfs, and that has come
up for two kernel developers already where they just happened to not use
an initramfs for a kernel they built themselves and had SELinux left
disabled (no policy loaded) unwittingly.

So I'm not fundamentally opposed to having the support in /sbin/init as
well if that's feasible, but you'll need it to detect whether policy has
already been loaded and skip it if so or it will end up loading policy
twice on systems that are using the initramfs-based approach.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Policy loading: initramfs vs. patched /sbin/init

[Russell Coker]

http://etbe.coker.com.au/2008/07/24/se-linux-policy-loading/

Firstly above is the URL for the blog post in question, for the benefit of 
people who don't normally read Planet SE Linux.

On Friday 25 July 2008 12:08, Stephen Smalley <stephen.smalley@gmail.com> 
wrote:
> I saw your blog entry about policy loading on planet selinux - you ought
> to bring issues like that up on selinux list for discussion rather than
> just blogging about them.

If I had realised what was going on before the release of Fedora 9 I would 
have.  But it seems that the Red Hat people have made their decision, so the 
decisions about what to do for Debian and Ubuntu have to be made separately.

> First, to clarify, while Ubuntu and Fedora are initiating the policy
> load from the initramfs, they are taking the policy from the real root
> filesystem.  Thus, the policy is not being stored on the initramfs image
> and updates to policy do not require rebuilding the image.

I have been told that an Ubuntu initramfs generated for a non-SE system will 
not have the scripts in question installed.  So there is a need to regenerate 
the initramfs when converting to SE Linux.

> On the positive side, the initramfs-based approach does mean
> that /sbin/init from the real root automatically transitions into the
> right domain since policy is already loaded.

Saving one exec system call.

> And policy gets loaded no 
> matter what init is used or even if the user specifies an alternate
> init= program on the kernel command line.

As I noted in my blog post there are not many init programs.  Only two are 
commonly used, and one of them has the patch well supported for a long time.  
Deciding to patch two vastly different initramfs systems instead of one init 
system (which is very similar the other one) was never going to reduce pain.

> As you note, performing the load from initramfs can be problematic for
> systems that cannot or choose not to use an initramfs,

Not problematic, a major show-stopper!

> So I'm not fundamentally opposed to having the support in /sbin/init as
> well if that's feasible, but you'll need it to detect whether policy has
> already been loaded and skip it if so or it will end up loading policy
> twice on systems that are using the initramfs-based approach.

Caleb has suggested having the already patched SysV init for systems that 
can't use initramfs.  That means such detection would be required in that 
case.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Policy loading: initramfs vs. patched /sbin/init

[Stephen Smalley]

On Fri, 2008-07-25 at 13:35 +1000, Russell Coker wrote:
> http://etbe.coker.com.au/2008/07/24/se-linux-policy-loading/
> 
> Firstly above is the URL for the blog post in question, for the benefit of 
> people who don't normally read Planet SE Linux.
> 
> On Friday 25 July 2008 12:08, Stephen Smalley <stephen.smalley@gmail.com> 
> wrote:
> > I saw your blog entry about policy loading on planet selinux - you ought
> > to bring issues like that up on selinux list for discussion rather than
> > just blogging about them.
> 
> If I had realised what was going on before the release of Fedora 9 I would 
> have.  But it seems that the Red Hat people have made their decision, so the 
> decisions about what to do for Debian and Ubuntu have to be made separately.

I still think it merits upstream discussion so that we are all aware of
what decisions are being made and why.  Admittedly, that ought to have
been done in the Fedora case as well.

> > First, to clarify, while Ubuntu and Fedora are initiating the policy
> > load from the initramfs, they are taking the policy from the real root
> > filesystem.  Thus, the policy is not being stored on the initramfs image
> > and updates to policy do not require rebuilding the image.
> 
> I have been told that an Ubuntu initramfs generated for a non-SE system will 
> not have the scripts in question installed.  So there is a need to regenerate 
> the initramfs when converting to SE Linux.

True, but that's a one-time regeneration vs. per-policy-update.

> > On the positive side, the initramfs-based approach does mean
> > that /sbin/init from the real root automatically transitions into the
> > right domain since policy is already loaded.
> 
> Saving one exec system call.

Requiring init to re-exec itself was always a hack; this is cleaner and
closer to the original model where the kernel loaded policy before init
ever ran.

> > And policy gets loaded no 
> > matter what init is used or even if the user specifies an alternate
> > init= program on the kernel command line.
> 
> As I noted in my blog post there are not many init programs.  Only two are 
> commonly used, and one of them has the patch well supported for a long time.  
> Deciding to patch two vastly different initramfs systems instead of one init 
> system (which is very similar the other one) was never going to reduce pain.
> 
> > As you note, performing the load from initramfs can be problematic for
> > systems that cannot or choose not to use an initramfs,
> 
> Not problematic, a major show-stopper!

For such systems, yes.

> > So I'm not fundamentally opposed to having the support in /sbin/init as
> > well if that's feasible, but you'll need it to detect whether policy has
> > already been loaded and skip it if so or it will end up loading policy
> > twice on systems that are using the initramfs-based approach.
> 
> Caleb has suggested having the already patched SysV init for systems that 
> can't use initramfs.  That means such detection would be required in that 
> case.

Yes.  Detecting it likely requires mounting /proc and then calling
is_selinux_enabled(), since our current test for whether policy has been
loaded is based on /proc/self/attr/current value ("kernel" or not).



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Policy loading: initramfs vs. patched /sbin/init

[Russell Coker]

On Friday 25 July 2008 23:38, Stephen Smalley <stephen.smalley@gmail.com> 
wrote:
> > > First, to clarify, while Ubuntu and Fedora are initiating the policy
> > > load from the initramfs, they are taking the policy from the real root
> > > filesystem.  Thus, the policy is not being stored on the initramfs
> > > image and updates to policy do not require rebuilding the image.
> >
> > I have been told that an Ubuntu initramfs generated for a non-SE system
> > will not have the scripts in question installed.  So there is a need to
> > regenerate the initramfs when converting to SE Linux.
>
> True, but that's a one-time regeneration vs. per-policy-update.

Any time you regenerate an initramfs there is a risk that it will result in a 
non-bootable system.

The way Debian currently works is that existing initramfs images are replaced 
when there is an upgrade to the tools related to generating them.  I believe 
that this is a mistake, an initramfs that has been used to successfully boot 
the system is good by definition and should not be touched.

The Ubuntu changes in this regard have merely extended the scope of this 
mistake.

> > > On the positive side, the initramfs-based approach does mean
> > > that /sbin/init from the real root automatically transitions into the
> > > right domain since policy is already loaded.
> >
> > Saving one exec system call.
>
> Requiring init to re-exec itself was always a hack; this is cleaner and
> closer to the original model where the kernel loaded policy before init
> ever ran.

For a long time (as long as I remember - more than 10 years) SysV Init has had 
the ability to re-exec itself (while preserving state) for an upgrade.  To 
re-exec while preserving state across an upgrade while in the middle of 
operation is not a trivial task.  To exec before actually doing anything when 
there is no real state to be saved is however trivial.

> > > So I'm not fundamentally opposed to having the support in /sbin/init as
> > > well if that's feasible, but you'll need it to detect whether policy
> > > has already been loaded and skip it if so or it will end up loading
> > > policy twice on systems that are using the initramfs-based approach.
> >
> > Caleb has suggested having the already patched SysV init for systems that
> > can't use initramfs.  That means such detection would be required in that
> > case.
>
> Yes.  Detecting it likely requires mounting /proc and then calling
> is_selinux_enabled(), since our current test for whether policy has been
> loaded is based on /proc/self/attr/current value ("kernel" or not).

So it seems that having the initramfs load policy for upstart gives you the 
union of all possible disadvantages.  You have to support SysV Init loading 
it (for non-initramfs systems), you need to have SysV Init deal with the case 
where an initramfs has already loaded the policy, and you need to maintain 
two vastly different methods of loading policy (initramfs and Init - which is 
more work than maintaining two patched Init systems).

Not to mention that the options of including chroot in initramfs or mounting 
all the filesystems there are both hacks and both have disadvantages.

If the Fedora people want to support only one Init system and only machines 
that use initramfs then it works OK (as they have demonstrated with Fedora 
9).  But if you want to support multiple Init systems (in Debian we always 
like to offer users a choice), support hardware which can't use initramfs 
(Debian supports a huge range of hardware - many people have machines more 
than 10 years old), and support people who just don't want to use initramfs 
(choice again) then it's not such a good option.

I'm not sure how much choice the Ubuntu people are planning to offer their 
users.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.