On systems such as Arch Linux, all programs which are usually located in
/bin, /sbin, /usr/bin and /usr/sbin are present in /usr/bin and the
other locations are symbolic links to this directory. With such a
configuration, the file contexts which define types for files in
/bin, /sbin and /usr/sbin need to be duplicated to provide definitions
for /usr/bin/...
As the "/bin vs. /usr/bin" part of the needed definitions has already
been done with the "usr merge" patches, the next step consists in
duplicating file contexts for /usr/sbin. There are several ways of
doing so:
1/ Introduce file contexts for /usr/bin files which have file contexts
in /usr/sbin. This is quite difficult to maintain in the long run.
2/ Modify the file contexts at build time so that patterns which begin
with /usr/sbin are modified to /usr/bin/... This does not work in
practise because the tools do not support duplicate file contexts
definition for the same path pattern, and because refpolicy defines
/usr/bin/imapd as courier_pop_exec_t in courier.fc and /usr/sbin/imapd
as imapd_exec_t in uwimap.fc (is this a bug? It is the only conflict I
got).
3/ Replace /usr/sbin by /usr/s?bin everywhere. This worked fine but was
not really nice-looking/human-friendly. This also has been recently
broken by commit 2e7553db639b ("Create / to /usr equivalence for bin,
sbin, and lib, from Russell Coker."), which replaced
/usr/(.*/)?bin(/.*)? with /usr/bin(/.*)?, thus creating a pattern with a
higher priority than /usr/s?bin to define the type of files in /usr/bin.
In order to make this work again, this part needs to be reverted.
4/ Modify the file contexts at build time so that patterns which begin
with /usr/sbin are modified to /usr/s?bin/... I have been using
/usr/s?bin patterns for several years without experiencing issues so
this would work, with the same fix as described in the previous option.
5/ Move everything under /usr/bin and introduce "/usr/sbin /usr/bin" in
config/file_contexts.subs_dist.
As option 4 is the simplest to implement, do this when the new
SINGLE_USR_BIN variable is activated in build.conf.
---
Makefile | 6 ++++++
README | 5 +++++
Rules.modular | 4 ++--
Rules.monolithic | 2 +-
build.conf | 4 ++++
policy/modules/kernel/corecommands.fc | 2 +-
6 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index b10b21ee5665..be76d6415e0b 100644
--- a/Makefile
+++ b/Makefile
@@ -110,6 +110,12 @@ m4terminate := $(support)/fatal_error.m4
# use our own genhomedircon to make sure we have a known usable one,
# so policycoreutils updates are not required (RHEL4)
genhomedircon := $(PYTHON) -E $(support)/genhomedircon
+# Replace /usr/sbin with /usr/s?bin in file contexts
+ifeq ($(SINGLE_USR_BIN),y)
+sed_single_usr_bin = $(SED) 's:^/usr/sbin:/usr/s?bin:'
+else
+sed_single_usr_bin = cat
+endif
# documentation paths
docs := doc
diff --git a/README b/README
index 7ac92f25d673..707769eb4808 100644
--- a/README
+++ b/README
@@ -125,6 +125,11 @@ UBAC Boolean. If set, the SELinux user will be used
SYSTEMD Boolean. If set, systemd will be assumed to be the init
process provider.
+SINGLE_USR_BIN Boolean. If set, the system will be assumed to have a
+ single /usr/bin directory for files usually located in
+ /usr/bin and /usr/sbin. The build system will replace
+ /usr/sbin with /usr/s?bin in every pattern.
+
MLS_SENS Integer. Set the number of sensitivities in the MLS
policy. Ignored on standard and MCS policies.
diff --git a/Rules.modular b/Rules.modular
index 49d3cca91e33..03a06129d79c 100644
--- a/Rules.modular
+++ b/Rules.modular
@@ -79,7 +79,7 @@ $(tmpdir)/%.mod: $(m4support) $(tmpdir)/generated_definitions.conf $(tmpdir)/all
$(tmpdir)/%.mod.fc: $(m4support) %.fc
@test -d $(tmpdir) || mkdir -p $(tmpdir)
- $(verbose) $(M4) $(M4PARAM) $(m4support) $^ > $@
+ $(verbose) $(M4) $(M4PARAM) $(m4support) $^ | $(sed_single_usr_bin) > $@
$(builddir)%.pp: $(tmpdir)/%.mod $(tmpdir)/%.mod.fc
@echo "Creating $(NAME) $(@F) policy package"
@@ -187,7 +187,7 @@ ifeq ($(base_fc_files),)
endif
@echo "Creating $(NAME) base module file contexts."
@test -d $(tmpdir) || mkdir -p $(tmpdir)
- $(verbose) $(M4) $(M4PARAM) $^ > $@
+ $(verbose) $(M4) $(M4PARAM) $^ | $(sed_single_usr_bin) > $@
########################################
#
diff --git a/Rules.monolithic b/Rules.monolithic
index ce112d788780..daf7cc63d009 100644
--- a/Rules.monolithic
+++ b/Rules.monolithic
@@ -179,7 +179,7 @@ ifeq ($(all_fc_files),)
endif
@echo "Creating $(NAME) file_contexts."
@test -d $(tmpdir) || mkdir -p $(tmpdir)
- $(verbose) $(M4) $(M4PARAM) $^ > $@
+ $(verbose) $(M4) $(M4PARAM) $^ | $(sed_single_usr_bin) > $@
$(homedir_template): $(fc)
diff --git a/build.conf b/build.conf
index a2f1a9b5bbd4..fad93dfa5010 100644
--- a/build.conf
+++ b/build.conf
@@ -48,6 +48,10 @@ DIRECT_INITRC = n
# Setting this will configure systemd as the init system.
SYSTEMD = n
+# Single /usr/bin directory
+# Putting y here will replace /usr/sbin file contexts with /usr/s?bin
+SINGLE_USR_BIN = n
+
# Build monolithic policy. Putting y here
# will build a monolithic policy.
MONOLITHIC = n
diff --git a/policy/modules/kernel/corecommands.fc b/policy/modules/kernel/corecommands.fc
index 3aeeb7f1af68..2a627a4f8fd3 100644
--- a/policy/modules/kernel/corecommands.fc
+++ b/policy/modules/kernel/corecommands.fc
@@ -135,7 +135,7 @@ ifdef(`distro_gentoo',`
# /usr
#
/usr/(.*/)?Bin(/.*)? gen_context(system_u:object_r:bin_t,s0)
-/usr/bin(/.*)? gen_context(system_u:object_r:bin_t,s0)
+/usr/(.*/)?bin(/.*)? gen_context(system_u:object_r:bin_t,s0)
/usr/bin/d?ash -- gen_context(system_u:object_r:shell_exec_t,s0)
/usr/bin/bash -- gen_context(system_u:object_r:shell_exec_t,s0)
/usr/bin/bash2 -- gen_context(system_u:object_r:shell_exec_t,s0)
--
2.11.1
On Mon, 6 Mar 2017 01:36:59 AM Nicolas Iooss via refpolicy wrote:
> 4/ Modify the file contexts at build time so that patterns which begin
> with /usr/sbin are modified to /usr/s?bin/... I have been using
> /usr/s?bin patterns for several years without experiencing issues so
> this would work, with the same fix as described in the previous option.
>
> 5/ Move everything under /usr/bin and introduce "/usr/sbin /usr/bin" in
> config/file_contexts.subs_dist.
>
> As option 4 is the simplest to implement, do this when the new
> SINGLE_USR_BIN variable is activated in build.conf.
Option 5 is quite easy to implement, it's a lot easier than the "usr merge"
patch I wrote. Option 4 doesn't seem to be such an easy option, I'll take
your word for it that it's not so hard, but I doubt it could be easier than
option 5.
What do you think will happen with other distributions in this regard? If
they will do it too then option 5 would be the obvious correct solution.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Mon, Mar 6, 2017 at 8:22 AM, Russell Coker <[email protected]> wrote:
> On Mon, 6 Mar 2017 01:36:59 AM Nicolas Iooss via refpolicy wrote:
>> 4/ Modify the file contexts at build time so that patterns which begin
>> with /usr/sbin are modified to /usr/s?bin/... I have been using
>> /usr/s?bin patterns for several years without experiencing issues so
>> this would work, with the same fix as described in the previous option.
>>
>> 5/ Move everything under /usr/bin and introduce "/usr/sbin /usr/bin" in
>> config/file_contexts.subs_dist.
>>
>> As option 4 is the simplest to implement, do this when the new
>> SINGLE_USR_BIN variable is activated in build.conf.
>
> Option 5 is quite easy to implement, it's a lot easier than the "usr merge"
> patch I wrote. Option 4 doesn't seem to be such an easy option, I'll take
> your word for it that it's not so hard, but I doubt it could be easier than
> option 5.
Option 4 is what my patch implements: it runs "sed
's:^/usr/sbin:/usr/s?bin:'" when generating tmp/....mod.fc files. I
said it was simple mainly because the patch that implements it is
quite small.
> What do you think will happen with other distributions in this regard? If
> they will do it too then option 5 would be the obvious correct solution.
I have not heard anything about projects to merge /usr/sbin with
/usr/bin in any other distribution than Arch Linux-based ones and Arch
Linux has done it nearly 4 years ago
(https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/).
As I expect such a change to be handled like the /usr merge (with an
announcement so that packages get updated), I believe it will not
happen in the near future.
Cheers,
Nicolas
On 03/07/17 17:16, Nicolas Iooss via refpolicy wrote:
> On Mon, Mar 6, 2017 at 8:22 AM, Russell Coker <[email protected]> wrote:
>> On Mon, 6 Mar 2017 01:36:59 AM Nicolas Iooss via refpolicy wrote:
>>> 4/ Modify the file contexts at build time so that patterns which begin
>>> with /usr/sbin are modified to /usr/s?bin/... I have been using
>>> /usr/s?bin patterns for several years without experiencing issues so
>>> this would work, with the same fix as described in the previous option.
>>>
>>> 5/ Move everything under /usr/bin and introduce "/usr/sbin /usr/bin" in
>>> config/file_contexts.subs_dist.
>>>
>>> As option 4 is the simplest to implement, do this when the new
>>> SINGLE_USR_BIN variable is activated in build.conf.
>>
>> Option 5 is quite easy to implement, it's a lot easier than the "usr merge"
>> patch I wrote. Option 4 doesn't seem to be such an easy option, I'll take
>> your word for it that it's not so hard, but I doubt it could be easier than
>> option 5.
>
> Option 4 is what my patch implements: it runs "sed
> 's:^/usr/sbin:/usr/s?bin:'" when generating tmp/....mod.fc files. I
> said it was simple mainly because the patch that implements it is
> quite small.
>
>> What do you think will happen with other distributions in this regard? If
>> they will do it too then option 5 would be the obvious correct solution.
>
> I have not heard anything about projects to merge /usr/sbin with
> /usr/bin in any other distribution than Arch Linux-based ones and Arch
> Linux has done it nearly 4 years ago
> (https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/).
> As I expect such a change to be handled like the /usr merge (with an
> announcement so that packages get updated), I believe it will not
> happen in the near future.
I've been wondering about #5 myself. A lot of the differences between
bin and sbin seem to be very arbitrary. I don't think there's anything
to gain by treating them separately.
--
Chris PeBenito
On Wed, 8 Mar 2017 12:13:50 PM Chris PeBenito via refpolicy wrote:
> >> What do you think will happen with other distributions in this
> >> regard? If they will do it too then option 5 would be the obvious
> >> correct solution.
> >
> > I have not heard anything about projects to merge /usr/sbin with
> > /usr/bin in any other distribution than Arch Linux-based ones and Arch
> > Linux has done it nearly 4 years ago
> > (https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-
> > intervention/). As I expect such a change to be handled like the /usr
> > merge (with an announcement so that packages get updated), I believe it
> > will not happen in the near future.
>
> I've been wondering about #5 myself. A lot of the differences between
> bin and sbin seem to be very arbitrary. I don't think there's anything
> to gain by treating them separately.
I've done a quick grep and sort for unique names between /usr/bin and
/usr/sbin and found that there are 1129 unique entries and 39 duplicates. I
only checked for obvious duplicates, there could be less obvious ones like
"ab[cd]" vs separate entries for "abc" and "abd".
These duplicates increase the possibility of a policy change relabelling an
executable not covering all instances.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/