| Message ID | 20200206131253.535302-3-omosnace@redhat.com (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
| Series | userspace: Allow changing version of kernel policy built by semodule | expand |
On 2/6/20 8:12 AM, Ondrej Mosnacek wrote: > When using semodule for building a distribution policy package (as > Fedora does), the environment might not have selinuxfs available and > provide no way to modify semanage.conf. When we want to build a policy > with version X (because our kernel doesn't support X+1 and above yet), > but our libsepol already has support for X+1, then we currently have no > way to do so. Not fundamentally opposed, but unclear on the motivation. The current approach is to generate the highest policy version supported by our libsepol at build time, then libselinux selinux_mkload_policy() uses libsepol functions (sepol_policydb_set_vers(), sepol_policydb_to_image()) to automatically downgrade the policy in memory to whatever version is supported by the kernel before writing it to the kernel. This works as long as one uses the same or newer libsepol at load time as at build time and as long as policydb_write() supports writing older policy versions (generally discarding newer features). > > To resolve this, add a new command-line argument to semodule, which > allows to override the system-wide configured version to a different > one. > > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> > --- > policycoreutils/semodule/semodule.8 | 3 +++ > policycoreutils/semodule/semodule.c | 12 +++++++++++- > 2 files changed, 14 insertions(+), 1 deletion(-) > > diff --git a/policycoreutils/semodule/semodule.8 b/policycoreutils/semodule/semodule.8 > index 18d4f708..88e027fd 100644 > --- a/policycoreutils/semodule/semodule.8 > +++ b/policycoreutils/semodule/semodule.8 > @@ -64,6 +64,9 @@ A module is extracted as HLL by default. The name of the module written is > <module-name>.<lang_ext> > .SH "OPTIONS" > .TP > +.B \-V,\-\-policyvers > +force specific kernel policy version > +.TP > .B \-s,\-\-store > name of the store to operate on > .TP > diff --git a/policycoreutils/semodule/semodule.c b/policycoreutils/semodule/semodule.c > index a1f75e16..30c4495b 100644 > --- a/policycoreutils/semodule/semodule.c > +++ b/policycoreutils/semodule/semodule.c > @@ -50,6 +50,8 @@ static int build; > static int disable_dontaudit; > static int preserve_tunables; > static int ignore_module_cache; > +static unsigned policyvers; > +static int policyvers_set = 0; > static uint16_t priority; > static int priority_set = 0; > > @@ -137,6 +139,7 @@ static void usage(char *progname) > printf(" -d,--disable=MODULE_NAME disable module\n"); > printf(" -E,--extract=MODULE_NAME extract module\n"); > printf("Options:\n"); > + printf(" -V,--policyvers force specific kernel policy version\n"); > printf(" -s,--store name of the store to operate on\n"); > printf(" -N,-n,--noreload do not reload policy after commit\n"); > printf(" -h,--help print this message and quit\n"); > @@ -210,7 +213,7 @@ static void parse_command_line(int argc, char **argv) > no_reload = 0; > priority = 400; > while ((i = > - getopt_long(argc, argv, "s:b:hi:l::vr:u:RnNBDCPX:e:d:p:S:E:cH", opts, > + getopt_long(argc, argv, "V:s:b:hi:l::vr:u:RnNBDCPX:e:d:p:S:E:cH", opts, > NULL)) != -1) { > switch (i) { > case 'b': > @@ -248,6 +251,10 @@ static void parse_command_line(int argc, char **argv) > fprintf(stderr, "The --upgrade option is deprecated. Use --install instead.\n"); > set_mode(INSTALL_M, optarg); > break; > + case 'V': > + policyvers = (unsigned)strtoul(optarg, NULL, 10); > + policyvers_set = 1; > + break; > case 's': > set_store(optarg); > break; > @@ -363,6 +370,9 @@ int main(int argc, char *argv[]) > goto cleanup_nohandle; > } > > + if (policyvers_set) > + semanage_set_policyvers(sh, policyvers); > + > if (store) { > /* Set the store we want to connect to, before connecting. > * this will always set a direct connection now, an additional >
On Thu, Feb 6, 2020 at 2:44 PM Stephen Smalley <sds@tycho.nsa.gov> wrote: > On 2/6/20 8:12 AM, Ondrej Mosnacek wrote: > > When using semodule for building a distribution policy package (as > > Fedora does), the environment might not have selinuxfs available and > > provide no way to modify semanage.conf. When we want to build a policy > > with version X (because our kernel doesn't support X+1 and above yet), > > but our libsepol already has support for X+1, then we currently have no > > way to do so. > > Not fundamentally opposed, but unclear on the motivation. The current > approach is to generate the highest policy version supported by our > libsepol at build time, then libselinux selinux_mkload_policy() uses > libsepol functions (sepol_policydb_set_vers(), > sepol_policydb_to_image()) to automatically downgrade the policy in > memory to whatever version is supported by the kernel before writing it > to the kernel. This works as long as one uses the same or newer > libsepol at load time as at build time and as long as policydb_write() > supports writing older policy versions (generally discarding newer > features). The problem is that: 1. selinux-policy expects that the generated /etc/selinux/.../policy.X file will be generated with a specific (hard-coded) value X, so if the userspace is updated in buildroot, the selinux-policy build fails. 2. If we fix the above by expecting any value X and ship that, then the build passes in such case, but if a user updates selinux-policy without updating userspace and reboots, the system will not boot. So even if we stop incrementing the expected policy version manually, we would still need to manually increment the minimum required userspace version each time the policy is rebuilt with userspace that has incremented its max policyvers. With these patches we can call semodule -V %{POLICYVER} ... and new rebuilds of selinux-policy wouldn't be disrupted by userspace upgrades. The only downside is that we would need to remember to increment the specfile versions from time to time. OTOH, maybe the build failure is actually a good thing in that it serves as a reminder to bump all the hard-coded versions whenever userspace bumps max policyvers... > > > > > To resolve this, add a new command-line argument to semodule, which > > allows to override the system-wide configured version to a different > > one. > > > > Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> > > --- > > policycoreutils/semodule/semodule.8 | 3 +++ > > policycoreutils/semodule/semodule.c | 12 +++++++++++- > > 2 files changed, 14 insertions(+), 1 deletion(-) > > > > diff --git a/policycoreutils/semodule/semodule.8 b/policycoreutils/semodule/semodule.8 > > index 18d4f708..88e027fd 100644 > > --- a/policycoreutils/semodule/semodule.8 > > +++ b/policycoreutils/semodule/semodule.8 > > @@ -64,6 +64,9 @@ A module is extracted as HLL by default. The name of the module written is > > <module-name>.<lang_ext> > > .SH "OPTIONS" > > .TP > > +.B \-V,\-\-policyvers > > +force specific kernel policy version > > +.TP > > .B \-s,\-\-store > > name of the store to operate on > > .TP > > diff --git a/policycoreutils/semodule/semodule.c b/policycoreutils/semodule/semodule.c > > index a1f75e16..30c4495b 100644 > > --- a/policycoreutils/semodule/semodule.c > > +++ b/policycoreutils/semodule/semodule.c > > @@ -50,6 +50,8 @@ static int build; > > static int disable_dontaudit; > > static int preserve_tunables; > > static int ignore_module_cache; > > +static unsigned policyvers; > > +static int policyvers_set = 0; > > static uint16_t priority; > > static int priority_set = 0; > > > > @@ -137,6 +139,7 @@ static void usage(char *progname) > > printf(" -d,--disable=MODULE_NAME disable module\n"); > > printf(" -E,--extract=MODULE_NAME extract module\n"); > > printf("Options:\n"); > > + printf(" -V,--policyvers force specific kernel policy version\n"); > > printf(" -s,--store name of the store to operate on\n"); > > printf(" -N,-n,--noreload do not reload policy after commit\n"); > > printf(" -h,--help print this message and quit\n"); > > @@ -210,7 +213,7 @@ static void parse_command_line(int argc, char **argv) > > no_reload = 0; > > priority = 400; > > while ((i = > > - getopt_long(argc, argv, "s:b:hi:l::vr:u:RnNBDCPX:e:d:p:S:E:cH", opts, > > + getopt_long(argc, argv, "V:s:b:hi:l::vr:u:RnNBDCPX:e:d:p:S:E:cH", opts, > > NULL)) != -1) { > > switch (i) { > > case 'b': > > @@ -248,6 +251,10 @@ static void parse_command_line(int argc, char **argv) > > fprintf(stderr, "The --upgrade option is deprecated. Use --install instead.\n"); > > set_mode(INSTALL_M, optarg); > > break; > > + case 'V': > > + policyvers = (unsigned)strtoul(optarg, NULL, 10); > > + policyvers_set = 1; > > + break; > > case 's': > > set_store(optarg); > > break; > > @@ -363,6 +370,9 @@ int main(int argc, char *argv[]) > > goto cleanup_nohandle; > > } > > > > + if (policyvers_set) > > + semanage_set_policyvers(sh, policyvers); > > + > > if (store) { > > /* Set the store we want to connect to, before connecting. > > * this will always set a direct connection now, an additional > > >
On 2/6/20 9:19 AM, Ondrej Mosnacek wrote: > On Thu, Feb 6, 2020 at 2:44 PM Stephen Smalley <sds@tycho.nsa.gov> wrote: >> On 2/6/20 8:12 AM, Ondrej Mosnacek wrote: >>> When using semodule for building a distribution policy package (as >>> Fedora does), the environment might not have selinuxfs available and >>> provide no way to modify semanage.conf. When we want to build a policy >>> with version X (because our kernel doesn't support X+1 and above yet), >>> but our libsepol already has support for X+1, then we currently have no >>> way to do so. >> >> Not fundamentally opposed, but unclear on the motivation. The current >> approach is to generate the highest policy version supported by our >> libsepol at build time, then libselinux selinux_mkload_policy() uses >> libsepol functions (sepol_policydb_set_vers(), >> sepol_policydb_to_image()) to automatically downgrade the policy in >> memory to whatever version is supported by the kernel before writing it >> to the kernel. This works as long as one uses the same or newer >> libsepol at load time as at build time and as long as policydb_write() >> supports writing older policy versions (generally discarding newer >> features). > > The problem is that: > 1. selinux-policy expects that the generated /etc/selinux/.../policy.X > file will be generated with a specific (hard-coded) value X, so if the > userspace is updated in buildroot, the selinux-policy build fails. > 2. If we fix the above by expecting any value X and ship that, then > the build passes in such case, but if a user updates selinux-policy > without updating userspace and reboots, the system will not boot. So > even if we stop incrementing the expected policy version manually, we > would still need to manually increment the minimum required userspace > version each time the policy is rebuilt with userspace that has > incremented its max policyvers. Seems like you could just have selinux-policy depend on the version of libsepol used to build it. The problem with both your current approach and your proposed one is that it means that if a user or package does a semodule -B (or any other semodule/semanage command) on their system, that will generate the latest policy.N version supported by their libsepol, and libselinux will give precedence to that policy at load time. So if they then later update their selinux-policy package, and it only installs a prebuilt policy.(N-1), that won't actually get loaded - libselinux selinux_mkload_policy() will keep using the policy.N file (which may be older). Unless I'm missing something. > With these patches we can call semodule -V %{POLICYVER} ... and new > rebuilds of selinux-policy wouldn't be disrupted by userspace > upgrades. The only downside is that we would need to remember to > increment the specfile versions from time to time. > > OTOH, maybe the build failure is actually a good thing in that it > serves as a reminder to bump all the hard-coded versions whenever > userspace bumps max policyvers...
On Thu, Feb 6, 2020 at 3:52 PM Stephen Smalley <sds@tycho.nsa.gov> wrote: > > On 2/6/20 9:19 AM, Ondrej Mosnacek wrote: > > On Thu, Feb 6, 2020 at 2:44 PM Stephen Smalley <sds@tycho.nsa.gov> wrote: > >> On 2/6/20 8:12 AM, Ondrej Mosnacek wrote: > >>> When using semodule for building a distribution policy package (as > >>> Fedora does), the environment might not have selinuxfs available and > >>> provide no way to modify semanage.conf. When we want to build a policy > >>> with version X (because our kernel doesn't support X+1 and above yet), > >>> but our libsepol already has support for X+1, then we currently have no > >>> way to do so. > >> > >> Not fundamentally opposed, but unclear on the motivation. The current > >> approach is to generate the highest policy version supported by our > >> libsepol at build time, then libselinux selinux_mkload_policy() uses > >> libsepol functions (sepol_policydb_set_vers(), > >> sepol_policydb_to_image()) to automatically downgrade the policy in > >> memory to whatever version is supported by the kernel before writing it > >> to the kernel. This works as long as one uses the same or newer > >> libsepol at load time as at build time and as long as policydb_write() > >> supports writing older policy versions (generally discarding newer > >> features). > > > > The problem is that: > > 1. selinux-policy expects that the generated /etc/selinux/.../policy.X > > file will be generated with a specific (hard-coded) value X, so if the > > userspace is updated in buildroot, the selinux-policy build fails. > > 2. If we fix the above by expecting any value X and ship that, then > > the build passes in such case, but if a user updates selinux-policy > > without updating userspace and reboots, the system will not boot. So > > even if we stop incrementing the expected policy version manually, we > > would still need to manually increment the minimum required userspace > > version each time the policy is rebuilt with userspace that has > > incremented its max policyvers. > > Seems like you could just have selinux-policy depend on the version of > libsepol used to build it. > > The problem with both your current approach and your proposed one is > that it means that if a user or package does a semodule -B (or any other > semodule/semanage command) on their system, that will generate the > latest policy.N version supported by their libsepol, and libselinux will > give precedence to that policy at load time. So if they then later > update their selinux-policy package, and it only installs a prebuilt > policy.(N-1), that won't actually get loaded - libselinux > selinux_mkload_policy() will keep using the policy.N file (which may be > older). Unless I'm missing something. Hm, yes, you're right... It seems we have no other choice than to better handle the dependency between selinux-policy and libsepol. Please disregard this patch series. > > > With these patches we can call semodule -V %{POLICYVER} ... and new > > rebuilds of selinux-policy wouldn't be disrupted by userspace > > upgrades. The only downside is that we would need to remember to > > increment the specfile versions from time to time. > > > > OTOH, maybe the build failure is actually a good thing in that it > > serves as a reminder to bump all the hard-coded versions whenever > > userspace bumps max policyvers... >
On 2/6/20 10:28 AM, Ondrej Mosnacek wrote: > On Thu, Feb 6, 2020 at 3:52 PM Stephen Smalley <sds@tycho.nsa.gov> wrote: >> >> On 2/6/20 9:19 AM, Ondrej Mosnacek wrote: >>> On Thu, Feb 6, 2020 at 2:44 PM Stephen Smalley <sds@tycho.nsa.gov> wrote: >>>> On 2/6/20 8:12 AM, Ondrej Mosnacek wrote: >>>>> When using semodule for building a distribution policy package (as >>>>> Fedora does), the environment might not have selinuxfs available and >>>>> provide no way to modify semanage.conf. When we want to build a policy >>>>> with version X (because our kernel doesn't support X+1 and above yet), >>>>> but our libsepol already has support for X+1, then we currently have no >>>>> way to do so. >>>> >>>> Not fundamentally opposed, but unclear on the motivation. The current >>>> approach is to generate the highest policy version supported by our >>>> libsepol at build time, then libselinux selinux_mkload_policy() uses >>>> libsepol functions (sepol_policydb_set_vers(), >>>> sepol_policydb_to_image()) to automatically downgrade the policy in >>>> memory to whatever version is supported by the kernel before writing it >>>> to the kernel. This works as long as one uses the same or newer >>>> libsepol at load time as at build time and as long as policydb_write() >>>> supports writing older policy versions (generally discarding newer >>>> features). >>> >>> The problem is that: >>> 1. selinux-policy expects that the generated /etc/selinux/.../policy.X >>> file will be generated with a specific (hard-coded) value X, so if the >>> userspace is updated in buildroot, the selinux-policy build fails. >>> 2. If we fix the above by expecting any value X and ship that, then >>> the build passes in such case, but if a user updates selinux-policy >>> without updating userspace and reboots, the system will not boot. So >>> even if we stop incrementing the expected policy version manually, we >>> would still need to manually increment the minimum required userspace >>> version each time the policy is rebuilt with userspace that has >>> incremented its max policyvers. >> >> Seems like you could just have selinux-policy depend on the version of >> libsepol used to build it. >> >> The problem with both your current approach and your proposed one is >> that it means that if a user or package does a semodule -B (or any other >> semodule/semanage command) on their system, that will generate the >> latest policy.N version supported by their libsepol, and libselinux will >> give precedence to that policy at load time. So if they then later >> update their selinux-policy package, and it only installs a prebuilt >> policy.(N-1), that won't actually get loaded - libselinux >> selinux_mkload_policy() will keep using the policy.N file (which may be >> older). Unless I'm missing something. > > Hm, yes, you're right... It seems we have no other choice than to > better handle the dependency between selinux-policy and libsepol. > Please disregard this patch series. Historically, I think we got to this point because originally selinux-policy would run semodule from %post to generate the policy.N file at install time, thereby always generating the latest version supported, and then later switched to pre-building policy.N at package build time and just dropping it in place at install time to avoid the runtime and memory overhead. Particularly because it could otherwise fail at install time on low-memory systems/VMs. As a separate matter, one could possibly argue that libselinux selinux_mkload_policy() should give preference to the newest file (i.e. timestamp-based) rather than the latest policy version. But even if we were to make that change going forward, it won't help with existing distro releases.
On 2/6/20 10:35 AM, Stephen Smalley wrote: > On 2/6/20 10:28 AM, Ondrej Mosnacek wrote: >> On Thu, Feb 6, 2020 at 3:52 PM Stephen Smalley <sds@tycho.nsa.gov> wrote: >>> >>> On 2/6/20 9:19 AM, Ondrej Mosnacek wrote: >>>> On Thu, Feb 6, 2020 at 2:44 PM Stephen Smalley <sds@tycho.nsa.gov> >>>> wrote: >>> Seems like you could just have selinux-policy depend on the version of >>> libsepol used to build it. >>> >>> The problem with both your current approach and your proposed one is >>> that it means that if a user or package does a semodule -B (or any other >>> semodule/semanage command) on their system, that will generate the >>> latest policy.N version supported by their libsepol, and libselinux will >>> give precedence to that policy at load time. So if they then later >>> update their selinux-policy package, and it only installs a prebuilt >>> policy.(N-1), that won't actually get loaded - libselinux >>> selinux_mkload_policy() will keep using the policy.N file (which may be >>> older). Unless I'm missing something. >> >> Hm, yes, you're right... It seems we have no other choice than to >> better handle the dependency between selinux-policy and libsepol. >> Please disregard this patch series. > > Historically, I think we got to this point because originally > selinux-policy would run semodule from %post to generate the policy.N > file at install time, thereby always generating the latest version > supported, and then later switched to pre-building policy.N at package > build time and just dropping it in place at install time to avoid the > runtime and memory overhead. Particularly because it could otherwise > fail at install time on low-memory systems/VMs. > > As a separate matter, one could possibly argue that libselinux > selinux_mkload_policy() should give preference to the newest file (i.e. > timestamp-based) rather than the latest policy version. But even if we > were to make that change going forward, it won't help with existing > distro releases. I guess that doesn't help either since the timestamp of the policy.N file generated at package build may still be older than that of any locally generated one, even if the package was installed later.
On 2/6/20 1:47 PM, Stephen Smalley wrote: > On 2/6/20 10:35 AM, Stephen Smalley wrote: >> On 2/6/20 10:28 AM, Ondrej Mosnacek wrote: >>> On Thu, Feb 6, 2020 at 3:52 PM Stephen Smalley <sds@tycho.nsa.gov> >>> wrote: >>>> >>>> On 2/6/20 9:19 AM, Ondrej Mosnacek wrote: >>>>> On Thu, Feb 6, 2020 at 2:44 PM Stephen Smalley <sds@tycho.nsa.gov> >>>>> wrote: >>>> Seems like you could just have selinux-policy depend on the version of >>>> libsepol used to build it. >>>> >>>> The problem with both your current approach and your proposed one is >>>> that it means that if a user or package does a semodule -B (or any >>>> other >>>> semodule/semanage command) on their system, that will generate the >>>> latest policy.N version supported by their libsepol, and libselinux >>>> will >>>> give precedence to that policy at load time. So if they then later >>>> update their selinux-policy package, and it only installs a prebuilt >>>> policy.(N-1), that won't actually get loaded - libselinux >>>> selinux_mkload_policy() will keep using the policy.N file (which may be >>>> older). Unless I'm missing something. >>> >>> Hm, yes, you're right... It seems we have no other choice than to >>> better handle the dependency between selinux-policy and libsepol. >>> Please disregard this patch series. >> >> Historically, I think we got to this point because originally >> selinux-policy would run semodule from %post to generate the policy.N >> file at install time, thereby always generating the latest version >> supported, and then later switched to pre-building policy.N at package >> build time and just dropping it in place at install time to avoid the >> runtime and memory overhead. Particularly because it could otherwise >> fail at install time on low-memory systems/VMs. >> >> As a separate matter, one could possibly argue that libselinux >> selinux_mkload_policy() should give preference to the newest file >> (i.e. timestamp-based) rather than the latest policy version. But >> even if we were to make that change going forward, it won't help with >> existing distro releases. > > I guess that doesn't help either since the timestamp of the policy.N > file generated at package build may still be older than that of any > locally generated one, even if the package was installed later. Looks like selinux-policy.spec has preInstall and postInstall macros that are triggering a rebuild of policy (semodule -B) if there are any /etc/selinux/targeted/policy/policy.* files that differ from the packaged one. So if the user did a semodule -B or any other semodule/semanage command previously that generated a newer policy version (or the same version but with different contents) then the package install is going to run semodule -B and re-generate it anyway. I guess it isn't broken then.
diff --git a/policycoreutils/semodule/semodule.8 b/policycoreutils/semodule/semodule.8 index 18d4f708..88e027fd 100644 --- a/policycoreutils/semodule/semodule.8 +++ b/policycoreutils/semodule/semodule.8 @@ -64,6 +64,9 @@ A module is extracted as HLL by default. The name of the module written is <module-name>.<lang_ext> .SH "OPTIONS" .TP +.B \-V,\-\-policyvers +force specific kernel policy version +.TP .B \-s,\-\-store name of the store to operate on .TP diff --git a/policycoreutils/semodule/semodule.c b/policycoreutils/semodule/semodule.c index a1f75e16..30c4495b 100644 --- a/policycoreutils/semodule/semodule.c +++ b/policycoreutils/semodule/semodule.c @@ -50,6 +50,8 @@ static int build; static int disable_dontaudit; static int preserve_tunables; static int ignore_module_cache; +static unsigned policyvers; +static int policyvers_set = 0; static uint16_t priority; static int priority_set = 0; @@ -137,6 +139,7 @@ static void usage(char *progname) printf(" -d,--disable=MODULE_NAME disable module\n"); printf(" -E,--extract=MODULE_NAME extract module\n"); printf("Options:\n"); + printf(" -V,--policyvers force specific kernel policy version\n"); printf(" -s,--store name of the store to operate on\n"); printf(" -N,-n,--noreload do not reload policy after commit\n"); printf(" -h,--help print this message and quit\n"); @@ -210,7 +213,7 @@ static void parse_command_line(int argc, char **argv) no_reload = 0; priority = 400; while ((i = - getopt_long(argc, argv, "s:b:hi:l::vr:u:RnNBDCPX:e:d:p:S:E:cH", opts, + getopt_long(argc, argv, "V:s:b:hi:l::vr:u:RnNBDCPX:e:d:p:S:E:cH", opts, NULL)) != -1) { switch (i) { case 'b': @@ -248,6 +251,10 @@ static void parse_command_line(int argc, char **argv) fprintf(stderr, "The --upgrade option is deprecated. Use --install instead.\n"); set_mode(INSTALL_M, optarg); break; + case 'V': + policyvers = (unsigned)strtoul(optarg, NULL, 10); + policyvers_set = 1; + break; case 's': set_store(optarg); break; @@ -363,6 +370,9 @@ int main(int argc, char *argv[]) goto cleanup_nohandle; } + if (policyvers_set) + semanage_set_policyvers(sh, policyvers); + if (store) { /* Set the store we want to connect to, before connecting. * this will always set a direct connection now, an additional
When using semodule for building a distribution policy package (as Fedora does), the environment might not have selinuxfs available and provide no way to modify semanage.conf. When we want to build a policy with version X (because our kernel doesn't support X+1 and above yet), but our libsepol already has support for X+1, then we currently have no way to do so. To resolve this, add a new command-line argument to semodule, which allows to override the system-wide configured version to a different one. Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> --- policycoreutils/semodule/semodule.8 | 3 +++ policycoreutils/semodule/semodule.c | 12 +++++++++++- 2 files changed, 14 insertions(+), 1 deletion(-)