Re: [PATCH] semodule-utils: remove semodule_deps

2017-10-03 Thread William Roberts 
On Tue, Oct 3, 2017 at 7:21 AM, Stephen Smalley  wrote:
> As discussed in https://github.com/SELinuxProject/selinux/issues/64,
> semodule_deps has apparently been broken for a very long time for
> binary modules and is completely irrelevant for CIL modules.  If there
> are any users of it, they ought to be rewritten anyway since it is
> not producing correct dependency information, and the ultimate goal
> is to stop using binary modules altogether so it is not worth fixing.
> Remove it to avoid any further broken usage.
>
> Signed-off-by: Stephen Smalley 
> ---
>  semodule-utils/.gitignore|   1 -
>  semodule-utils/Makefile  |   2 +-
>  semodule-utils/semodule_deps/Makefile|  28 --
>  semodule-utils/semodule_deps/semodule_deps.8 |  46 ---
>  semodule-utils/semodule_deps/semodule_deps.c | 401 
> ---
>  5 files changed, 1 insertion(+), 477 deletions(-)
>  delete mode 100644 semodule-utils/semodule_deps/Makefile
>  delete mode 100644 semodule-utils/semodule_deps/semodule_deps.8
>  delete mode 100644 semodule-utils/semodule_deps/semodule_deps.c
>
> diff --git a/semodule-utils/.gitignore b/semodule-utils/.gitignore
> index 1667564..6ec4efe 100644
> --- a/semodule-utils/.gitignore
> +++ b/semodule-utils/.gitignore
> @@ -1,5 +1,4 @@
>  semodule_package/semodule_package
>  semodule_package/semodule_unpackage
> -semodule_deps/semodule_deps
>  semodule_expand/semodule_expand
>  semodule_link/semodule_link
> diff --git a/semodule-utils/Makefile b/semodule-utils/Makefile
> index 6bf4aee..e0a6579 100644
> --- a/semodule-utils/Makefile
> +++ b/semodule-utils/Makefile
> @@ -1,4 +1,4 @@
> -SUBDIRS = semodule_package semodule_link semodule_expand semodule_deps
> +SUBDIRS = semodule_package semodule_link semodule_expand
>
>  all install relabel clean indent:
> @for subdir in $(SUBDIRS); do \
> diff --git a/semodule-utils/semodule_deps/Makefile 
> b/semodule-utils/semodule_deps/Makefile
> deleted file mode 100644
> index 328a503..000
> --- a/semodule-utils/semodule_deps/Makefile
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -# Installation directories.
> -PREFIX ?= $(DESTDIR)/usr
> -INCLUDEDIR ?= $(PREFIX)/include
> -BINDIR ?= $(PREFIX)/bin
> -LIBDIR ?= $(PREFIX)/lib
> -MANDIR ?= $(PREFIX)/share/man
> -LIBSEPOLA ?= $(LIBDIR)/libsepol.a
> -
> -CFLAGS ?= -Werror -Wall -W
> -
> -all: semodule_deps
> -
> -semodule_deps:  semodule_deps.o $(LIBSEPOLA)
> -
> -install: all
> -   -mkdir -p $(BINDIR)
> -   install -m 755 semodule_deps $(BINDIR)
> -   test -d $(MANDIR)/man8 || install -m 755 -d $(MANDIR)/man8
> -   install -m 644 semodule_deps.8 $(MANDIR)/man8/
> -
> -relabel:
> -
> -clean:
> -   -rm -f semodule_deps *.o
> -
> -indent:
> -   ../../scripts/Lindent $(wildcard *.[ch])
> -
> diff --git a/semodule-utils/semodule_deps/semodule_deps.8 
> b/semodule-utils/semodule_deps/semodule_deps.8
> deleted file mode 100644
> index 6f21a64..000
> --- a/semodule-utils/semodule_deps/semodule_deps.8
> +++ /dev/null
> @@ -1,46 +0,0 @@
> -.TH SEMODULE_DEPS "8" "June 2006" "Security Enhanced Linux" NSA
> -.SH NAME
> -semodule_deps \- show the dependencies between SELinux policy packages.
> -
> -.SH SYNOPSIS
> -.B semodule_deps [\-v \-g \-b] basemodpkg modpkg1 [modpkg2 ... ]
> -.br
> -.SH DESCRIPTION
> -.PP
> -semodule_deps is a developer tool for showing the dependencies
> -between policy packages. For each module it prints a list of
> -modules that must be present for a module's requirements to
> -be satisfied. It only deals with requirements, not optional
> -dependencies.
> -
> -In order for semodule_deps to give useful information the list
> -of packages passed in cannot have unsatisfied dependencies. In
> -general this means that the list of modules will usually be
> -quite long.
> -
> -By default options to the base module are excluded as almost every
> -module has this dependency. The \-b option will include these
> -dependencies.
> -
> -In addition to human readable output, semodule_deps can output the
> -dependencies in the Graphviz dot format (http://www.graphviz.org/)
> -using the \-g option. This is useful for producing a picture of the
> -dependencies.
> -
> -.SH "OPTIONS"
> -.TP
> -.B \-v
> -verbose mode
> -.TP
> -.B \-g
> -output dependency information in Graphviz dot format
> -.TP
> -.B \-b
> -include dependencies to the base module - by default these are excluded
> -
> -.SH SEE ALSO
> -.B checkmodule(8), semodule_package(8), semodule(8), semodule_link(8)
> -.SH AUTHORS
> -.nf
> -This manual page was written by Karl MacMillan 
> .
> -The program was written by Karl MacMillan .
> diff --git a/semodule-utils/semodule_deps/semodule_deps.c 
> b/semodule-utils/semodule_deps/semodule_deps.c
> deleted file mode 100644
> index 7a7ff2f..000
> --- a/semodule-utils/semodule_deps/semodule_deps.c
> +++ /dev/null
> @@ -1,401 +0,0 @@
> -/*

Re: [RFC 09/10] selinux: add a selinuxfs interface to unshare selinux namespace

2017-10-03 Thread Casey Schaufler 
On 10/3/2017 5:29 AM, Stephen Smalley wrote:
> On Mon, 2017-10-02 at 16:56 -0700, Casey Schaufler wrote:
>> On 10/2/2017 8:58 AM, Stephen Smalley wrote:
>>> Provide a userspace API to unshare the selinux namespace.
>>> Currently implemented via a selinuxfs node. This could be
>>> coupled with unsharing of other namespaces (e.g.  mount namespace,
>>> network namespace) that will always be needed or left independent.
>>> Don't get hung up on the interface itself, it is just to allow
>>> experimentation and testing.
>>>
>>> Sample usage:
>>> echo 1 > /sys/fs/selinux/unshare
>>> unshare -m -n
>>> umount /sys/fs/selinux
>>> mount -t selinuxfs none /sys/fs/selinux
>>> load_policy
>>> getenforce
>>> id
>>> echo $$
>>>
>>> The above will show that the process now views itself as running in
>>> the
>>> kernel domain in permissive mode, as would be the case at boot.
 From a different shell on the host system, running ps -eZ or
>>> cat /proc//attr/current will show that the process that
>>> unshared its selinux namespace is still running in its original
>>> context in the initial namespace, and getenforce will show the
>>> the initial namespace remains enforcing.  Enforcing mode or policy
>>> changes in the child will not affect the parent.
>>>
>>> This is not yet safe; do not use on production systems.
>>> Known issues include at least the following items:
>>>
>>> * The policy loading code has not been thoroughly audited
>>> and hardened for use by unprivileged code, both with respect to
>>> ensuring that the policy is internally consistent and restricting
>>> the range of values used from the policy as loop bounds and memory
>>> allocation sizes to sane limits.
>>>
>>> * The SELinux hook functions have not been modified to be
>>> namespace-aware, so the hooks only perform checking against the
>>> current namespace.  Thus, unsharing allows the process to escape
>>> confinement by the parent.  Fixing this requires updating each hook
>>> to
>>> perform its processing on the current namespace and all of its
>>> ancestors
>>> up to the init namespace.
>>>
>>> * Some of the hook functions can be called outside of process
>>> context
>>> (e.g. task_kill, send_sigiotask, network input/forward) and should
>>> not use
>>> the current task's selinux namespace. These hooks need to be
>>> updated to
>>> obtain the proper selinux namespace to use instead from the caller
>>> or
>>> cached in a suitable data structure (e.g. the file or sock security
>>> structures).
>>>
>>> * There are number of issues with the inode and superblock security
>>> blob
>>> handling for multiple namespaces, see those commits for more
>>> details.
>>>
>>> * Only a subset of object security blobs have been updated to
>>> be namespace-aware and support multiple namespaces.  The ones that
>>> have not yet been updated could end up performing permission checks
>>> or
>>> other operations on SIDs created in a different selinux namespace.
>>>
>>> * The network SID caches (netif, netnode, netport) have not yet
>>> been instantiated per selinux namespace, unlike the AVC and SS.
>>>
>>> * There is no way currently to restrict or bound nesting of
>>> namespaces; if you allow it to a domain in the init namespace,
>>> then that domain can in turn unshare to arbitrary depths and can
>>> grant the same to any domain in its own policy.  Related to this
>>> is the fact that there is no way to control resource usage due to
>>> selinux namespaces and they can be substantial (per-namespace
>>> policydb, sidtab, AVC, etc).
>>>
>>> * SIDs may be cached by audit and networking code and in external
>>> kernel data structures and used later, potentially in a different
>>> selinux namespace than the one in which the SID was originally
>>> created.
>> Is there a good reason that SIDs (and security contexts) need to
>> be maintained separately in the namespaces? Using the same secid
>> to map to a different context depending on the namespace seems like
>> you're asking for trouble you don't need. A namespace that hasn't
>> policy for a context/SID won't use it if it is defined for a
>> different namespace, and should detect the fact if it somehow gets
>> referenced, because it isn't in the policy.
>>
>> Do the context/SID mapping globally. Or, if you must duplicate
>> contexts,
>> allocate the SIDs from a single source so that they aren't ambiguous.
> Yes, that may be the right answer, but it requires introducing a new
> SID/context layer above the current security server layer (or changing
> the latter),

It could be as simple as using a global next_sid instead of attaching
that to the sidtab (s->next_sid).

What I'm really afraid of is an ambiguous secid being set in
a secmark. In the stacking case it's going to be bad enough
mapping a set of secids into a "token" without having to deal
with the possibility that SELinux could give you a secid that
has multiple possible mappings depending on which namespace it
came from and/or which it is going into.


>  because the

[PATCH] semodule-utils: remove semodule_deps

2017-10-03 Thread Stephen Smalley 
As discussed in https://github.com/SELinuxProject/selinux/issues/64,
semodule_deps has apparently been broken for a very long time for
binary modules and is completely irrelevant for CIL modules.  If there
are any users of it, they ought to be rewritten anyway since it is
not producing correct dependency information, and the ultimate goal
is to stop using binary modules altogether so it is not worth fixing.
Remove it to avoid any further broken usage.

Signed-off-by: Stephen Smalley 
---
 semodule-utils/.gitignore|   1 -
 semodule-utils/Makefile  |   2 +-
 semodule-utils/semodule_deps/Makefile|  28 --
 semodule-utils/semodule_deps/semodule_deps.8 |  46 ---
 semodule-utils/semodule_deps/semodule_deps.c | 401 ---
 5 files changed, 1 insertion(+), 477 deletions(-)
 delete mode 100644 semodule-utils/semodule_deps/Makefile
 delete mode 100644 semodule-utils/semodule_deps/semodule_deps.8
 delete mode 100644 semodule-utils/semodule_deps/semodule_deps.c

diff --git a/semodule-utils/.gitignore b/semodule-utils/.gitignore
index 1667564..6ec4efe 100644
--- a/semodule-utils/.gitignore
+++ b/semodule-utils/.gitignore
@@ -1,5 +1,4 @@
 semodule_package/semodule_package
 semodule_package/semodule_unpackage
-semodule_deps/semodule_deps
 semodule_expand/semodule_expand
 semodule_link/semodule_link
diff --git a/semodule-utils/Makefile b/semodule-utils/Makefile
index 6bf4aee..e0a6579 100644
--- a/semodule-utils/Makefile
+++ b/semodule-utils/Makefile
@@ -1,4 +1,4 @@
-SUBDIRS = semodule_package semodule_link semodule_expand semodule_deps
+SUBDIRS = semodule_package semodule_link semodule_expand
 
 all install relabel clean indent:
@for subdir in $(SUBDIRS); do \
diff --git a/semodule-utils/semodule_deps/Makefile 
b/semodule-utils/semodule_deps/Makefile
deleted file mode 100644
index 328a503..000
--- a/semodule-utils/semodule_deps/Makefile
+++ /dev/null
@@ -1,28 +0,0 @@
-# Installation directories.
-PREFIX ?= $(DESTDIR)/usr
-INCLUDEDIR ?= $(PREFIX)/include
-BINDIR ?= $(PREFIX)/bin
-LIBDIR ?= $(PREFIX)/lib
-MANDIR ?= $(PREFIX)/share/man
-LIBSEPOLA ?= $(LIBDIR)/libsepol.a
-
-CFLAGS ?= -Werror -Wall -W
-
-all: semodule_deps
-
-semodule_deps:  semodule_deps.o $(LIBSEPOLA)
-
-install: all
-   -mkdir -p $(BINDIR)
-   install -m 755 semodule_deps $(BINDIR)
-   test -d $(MANDIR)/man8 || install -m 755 -d $(MANDIR)/man8
-   install -m 644 semodule_deps.8 $(MANDIR)/man8/
-
-relabel:
-
-clean:
-   -rm -f semodule_deps *.o
-
-indent:
-   ../../scripts/Lindent $(wildcard *.[ch])
-
diff --git a/semodule-utils/semodule_deps/semodule_deps.8 
b/semodule-utils/semodule_deps/semodule_deps.8
deleted file mode 100644
index 6f21a64..000
--- a/semodule-utils/semodule_deps/semodule_deps.8
+++ /dev/null
@@ -1,46 +0,0 @@
-.TH SEMODULE_DEPS "8" "June 2006" "Security Enhanced Linux" NSA
-.SH NAME 
-semodule_deps \- show the dependencies between SELinux policy packages.
-
-.SH SYNOPSIS
-.B semodule_deps [\-v \-g \-b] basemodpkg modpkg1 [modpkg2 ... ]
-.br
-.SH DESCRIPTION
-.PP
-semodule_deps is a developer tool for showing the dependencies
-between policy packages. For each module it prints a list of
-modules that must be present for a module's requirements to
-be satisfied. It only deals with requirements, not optional
-dependencies.
-
-In order for semodule_deps to give useful information the list
-of packages passed in cannot have unsatisfied dependencies. In
-general this means that the list of modules will usually be
-quite long.
-
-By default options to the base module are excluded as almost every
-module has this dependency. The \-b option will include these
-dependencies.
-
-In addition to human readable output, semodule_deps can output the
-dependencies in the Graphviz dot format (http://www.graphviz.org/)
-using the \-g option. This is useful for producing a picture of the
-dependencies.
-
-.SH "OPTIONS"
-.TP
-.B \-v
-verbose mode
-.TP
-.B \-g
-output dependency information in Graphviz dot format
-.TP
-.B \-b
-include dependencies to the base module - by default these are excluded
-
-.SH SEE ALSO
-.B checkmodule(8), semodule_package(8), semodule(8), semodule_link(8)
-.SH AUTHORS
-.nf
-This manual page was written by Karl MacMillan .
-The program was written by Karl MacMillan .
diff --git a/semodule-utils/semodule_deps/semodule_deps.c 
b/semodule-utils/semodule_deps/semodule_deps.c
deleted file mode 100644
index 7a7ff2f..000
--- a/semodule-utils/semodule_deps/semodule_deps.c
+++ /dev/null
@@ -1,401 +0,0 @@
-/* Authors: Karl MacMillan 
- *
- * Copyright (C) 2006 Tresys Technology, LLC
- * Copyright (C) 2006-2007 Red Hat, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation, version 2.
- *
- */

Re: Labeling sysfs files

2017-10-03 Thread David Graziano 
On Tue, Oct 3, 2017 at 7:58 AM, Stephen Smalley  wrote:
> On Mon, 2017-10-02 at 16:54 -0500, David Graziano wrote:
>> I'm trying to find a way of labeling specific files/directories in
>> sysfs that do not exist at boot time. I'm running an embedded SELinux
>> enabled system (4.1 series kernel) where at boot there is an init
>> script performing a restorecon on /sys.  Sometime later a usb
>> cellular
>> modem is powered on and enumerated at which point the it's sysfs
>> sub-directory structure is added.
>>
>> This directory path is correctly getting my custom label via
>> restorecon during boot
>> /sys/devices/platform///fsl-ehci.0/usb1/
>>
>> After the cellular modem is powered on the following directory
>> structure is created.
>> /sys/devices/platform///fsl-ehci.0/usb1/1-1/1-
>> 1:1.10/net/wwan1/qmi
>> Everything "1-1" and lower that is getting the "default" sysfs_t
>> label.
>>
>> Is there a method of labeling that newly added sub-directory
>> structure
>> other than running restorecond or restorecon again? I specifically
>> need to control access to the "qmi" file. I've tried adding a
>> genfscon
>> to the policy but it doesn't seem to work although I don't know if
>> it's suppose to.
>>
>> Any advice would be appreciated.
>
> You could cherry-pick kernel commits
> 134509d54e4e9be2697a92cb4b48957b792b and
> 8e01472078763ebc1eaea089a1adab75dd982ccd to gain support for genfscon
> labeling of sysfs entries.  Looks like they apply ok on 4.1, although I
> haven't built or tested that. I think that's your best option.
>

Thanks for the info. I will try cherry-picking those commits.
- David

Re: Labeling sysfs files

2017-10-03 Thread Stephen Smalley 
On Mon, 2017-10-02 at 16:54 -0500, David Graziano wrote:
> I'm trying to find a way of labeling specific files/directories in
> sysfs that do not exist at boot time. I'm running an embedded SELinux
> enabled system (4.1 series kernel) where at boot there is an init
> script performing a restorecon on /sys.  Sometime later a usb
> cellular
> modem is powered on and enumerated at which point the it's sysfs
> sub-directory structure is added.
> 
> This directory path is correctly getting my custom label via
> restorecon during boot
> /sys/devices/platform///fsl-ehci.0/usb1/
> 
> After the cellular modem is powered on the following directory
> structure is created.
> /sys/devices/platform///fsl-ehci.0/usb1/1-1/1-
> 1:1.10/net/wwan1/qmi
> Everything "1-1" and lower that is getting the "default" sysfs_t
> label.
> 
> Is there a method of labeling that newly added sub-directory
> structure
> other than running restorecond or restorecon again? I specifically
> need to control access to the "qmi" file. I've tried adding a
> genfscon
> to the policy but it doesn't seem to work although I don't know if
> it's suppose to.
> 
> Any advice would be appreciated.

You could cherry-pick kernel commits
134509d54e4e9be2697a92cb4b48957b792b and
8e01472078763ebc1eaea089a1adab75dd982ccd to gain support for genfscon
labeling of sysfs entries.  Looks like they apply ok on 4.1, although I
haven't built or tested that. I think that's your best option.

Re: [RFC 09/10] selinux: add a selinuxfs interface to unshare selinux namespace

2017-10-03 Thread Stephen Smalley 
On Mon, 2017-10-02 at 16:56 -0700, Casey Schaufler wrote:
> On 10/2/2017 8:58 AM, Stephen Smalley wrote:
> > Provide a userspace API to unshare the selinux namespace.
> > Currently implemented via a selinuxfs node. This could be
> > coupled with unsharing of other namespaces (e.g.  mount namespace,
> > network namespace) that will always be needed or left independent.
> > Don't get hung up on the interface itself, it is just to allow
> > experimentation and testing.
> > 
> > Sample usage:
> > echo 1 > /sys/fs/selinux/unshare
> > unshare -m -n
> > umount /sys/fs/selinux
> > mount -t selinuxfs none /sys/fs/selinux
> > load_policy
> > getenforce
> > id
> > echo $$
> > 
> > The above will show that the process now views itself as running in
> > the
> > kernel domain in permissive mode, as would be the case at boot.
> > > From a different shell on the host system, running ps -eZ or
> > 
> > cat /proc//attr/current will show that the process that
> > unshared its selinux namespace is still running in its original
> > context in the initial namespace, and getenforce will show the
> > the initial namespace remains enforcing.  Enforcing mode or policy
> > changes in the child will not affect the parent.
> > 
> > This is not yet safe; do not use on production systems.
> > Known issues include at least the following items:
> > 
> > * The policy loading code has not been thoroughly audited
> > and hardened for use by unprivileged code, both with respect to
> > ensuring that the policy is internally consistent and restricting
> > the range of values used from the policy as loop bounds and memory
> > allocation sizes to sane limits.
> > 
> > * The SELinux hook functions have not been modified to be
> > namespace-aware, so the hooks only perform checking against the
> > current namespace.  Thus, unsharing allows the process to escape
> > confinement by the parent.  Fixing this requires updating each hook
> > to
> > perform its processing on the current namespace and all of its
> > ancestors
> > up to the init namespace.
> > 
> > * Some of the hook functions can be called outside of process
> > context
> > (e.g. task_kill, send_sigiotask, network input/forward) and should
> > not use
> > the current task's selinux namespace. These hooks need to be
> > updated to
> > obtain the proper selinux namespace to use instead from the caller
> > or
> > cached in a suitable data structure (e.g. the file or sock security
> > structures).
> > 
> > * There are number of issues with the inode and superblock security
> > blob
> > handling for multiple namespaces, see those commits for more
> > details.
> > 
> > * Only a subset of object security blobs have been updated to
> > be namespace-aware and support multiple namespaces.  The ones that
> > have not yet been updated could end up performing permission checks
> > or
> > other operations on SIDs created in a different selinux namespace.
> > 
> > * The network SID caches (netif, netnode, netport) have not yet
> > been instantiated per selinux namespace, unlike the AVC and SS.
> > 
> > * There is no way currently to restrict or bound nesting of
> > namespaces; if you allow it to a domain in the init namespace,
> > then that domain can in turn unshare to arbitrary depths and can
> > grant the same to any domain in its own policy.  Related to this
> > is the fact that there is no way to control resource usage due to
> > selinux namespaces and they can be substantial (per-namespace
> > policydb, sidtab, AVC, etc).
> > 
> > * SIDs may be cached by audit and networking code and in external
> > kernel data structures and used later, potentially in a different
> > selinux namespace than the one in which the SID was originally
> > created.
> 
> Is there a good reason that SIDs (and security contexts) need to
> be maintained separately in the namespaces? Using the same secid
> to map to a different context depending on the namespace seems like
> you're asking for trouble you don't need. A namespace that hasn't
> policy for a context/SID won't use it if it is defined for a
> different namespace, and should detect the fact if it somehow gets
> referenced, because it isn't in the policy.
> 
> Do the context/SID mapping globally. Or, if you must duplicate
> contexts,
> allocate the SIDs from a single source so that they aren't ambiguous.

Yes, that may be the right answer, but it requires introducing a new
SID/context layer above the current security server layer (or changing
the latter), because the security server SID/context mappings are from
SIDs to internal struct representations of the context, where the
struct representation is policy-specific.  Also, certain SIDs (e.g. the
kernel SID, the unlabeled SID, etc) are predefined for system
initialization before policy load and to support usage from policy-
independent code, but may be mapped to different context values by
different policies.  So even the SID->string mappings may differ for
different policies, and hence for different namespaces.

>

[PATCH] libsemanage: Add support for listing fcontext.homedirs file

2017-10-03 Thread Vit Mojzis 
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1409813
---
 libsemanage/include/semanage/fcontexts_policy.h |  4 
 libsemanage/src/direct_api.c|  7 +++
 libsemanage/src/fcontexts_policy.c  |  8 
 libsemanage/src/handle.h| 19 +--
 4 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/libsemanage/include/semanage/fcontexts_policy.h 
b/libsemanage/include/semanage/fcontexts_policy.h
index a50db2b..199a1e1 100644
--- a/libsemanage/include/semanage/fcontexts_policy.h
+++ b/libsemanage/include/semanage/fcontexts_policy.h
@@ -26,4 +26,8 @@ extern int semanage_fcontext_list(semanage_handle_t * handle,
  semanage_fcontext_t *** records,
  unsigned int *count);
 
+extern int semanage_fcontext_list_homedirs(semanage_handle_t * handle,
+ semanage_fcontext_t *** records,
+ unsigned int *count);
+
 #endif
diff --git a/libsemanage/src/direct_api.c b/libsemanage/src/direct_api.c
index 971a08f..00ad820 100644
--- a/libsemanage/src/direct_api.c
+++ b/libsemanage/src/direct_api.c
@@ -210,6 +210,12 @@ int semanage_direct_connect(semanage_handle_t * sh)
 semanage_fcontext_dbase_local(sh)) < 0)
goto err;
 
+   if (fcontext_file_dbase_init(sh,
+semanage_path(SEMANAGE_ACTIVE, 
SEMANAGE_STORE_FC_HOMEDIRS),
+semanage_path(SEMANAGE_TMP, 
SEMANAGE_STORE_FC_HOMEDIRS),
+semanage_fcontext_dbase_homedirs(sh)) < 0)
+   goto err;
+
if (seuser_file_dbase_init(sh,
   semanage_path(SEMANAGE_ACTIVE,
 SEMANAGE_SEUSERS_LOCAL),
@@ -349,6 +355,7 @@ static int semanage_direct_disconnect(semanage_handle_t * 
sh)
iface_file_dbase_release(semanage_iface_dbase_local(sh));
bool_file_dbase_release(semanage_bool_dbase_local(sh));
fcontext_file_dbase_release(semanage_fcontext_dbase_local(sh));
+   fcontext_file_dbase_release(semanage_fcontext_dbase_homedirs(sh));
seuser_file_dbase_release(semanage_seuser_dbase_local(sh));
node_file_dbase_release(semanage_node_dbase_local(sh));
 
diff --git a/libsemanage/src/fcontexts_policy.c 
b/libsemanage/src/fcontexts_policy.c
index 0b063b1..98490ab 100644
--- a/libsemanage/src/fcontexts_policy.c
+++ b/libsemanage/src/fcontexts_policy.c
@@ -51,3 +51,11 @@ int semanage_fcontext_list(semanage_handle_t * handle,
dbase_config_t *dconfig = semanage_fcontext_dbase_policy(handle);
return dbase_list(handle, dconfig, records, count);
 }
+
+int semanage_fcontext_list_homedirs(semanage_handle_t * handle,
+  semanage_fcontext_t *** records, unsigned int *count)
+{
+
+   dbase_config_t *dconfig = semanage_fcontext_dbase_homedirs(handle);
+   return dbase_list(handle, dconfig, records, count);
+}
diff --git a/libsemanage/src/handle.h b/libsemanage/src/handle.h
index 889871d..1780ac8 100644
--- a/libsemanage/src/handle.h
+++ b/libsemanage/src/handle.h
@@ -79,7 +79,7 @@ struct semanage_handle {
struct semanage_policy_table *funcs;
 
/* Object databases */
-#define DBASE_COUNT  23
+#define DBASE_COUNT  24
 
 /* Local modifications */
 #define DBASE_LOCAL_USERS_BASE  0
@@ -102,13 +102,14 @@ struct semanage_handle {
 #define DBASE_POLICY_INTERFACES  15
 #define DBASE_POLICY_BOOLEANS16
 #define DBASE_POLICY_FCONTEXTS   17
-#define DBASE_POLICY_SEUSERS 18
-#define DBASE_POLICY_NODES   19
-#define DBASE_POLICY_IBPKEYS 20
-#define DBASE_POLICY_IBENDPORTS  21
+#define DBASE_POLICY_FCONTEXTS_H 18
+#define DBASE_POLICY_SEUSERS 19
+#define DBASE_POLICY_NODES   20
+#define DBASE_POLICY_IBPKEYS 21
+#define DBASE_POLICY_IBENDPORTS  22
 
 /* Active kernel policy */
-#define DBASE_ACTIVE_BOOLEANS22
+#define DBASE_ACTIVE_BOOLEANS23
dbase_config_t dbase[DBASE_COUNT];
 };
 
@@ -236,6 +237,12 @@ static inline
 }
 
 static inline
+dbase_config_t * semanage_fcontext_dbase_homedirs(semanage_handle_t * 
handle)
+{
+   return >dbase[DBASE_POLICY_FCONTEXTS_H];
+}
+
+static inline
 dbase_config_t * semanage_seuser_dbase_policy(semanage_handle_t * handle)
 {
return >dbase[DBASE_POLICY_SEUSERS];
-- 
2.9.4

Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute

2017-10-03 Thread Lukas Vrabec 

On 08/02/2017 09:01 PM, Dominick Grift wrote:

On Wed, Aug 02, 2017 at 02:59:34PM -0400, Stephen Smalley wrote:

On Wed, 2017-08-02 at 18:35 +0200, Dominick Grift wrote:

On Wed, Aug 02, 2017 at 04:41:00PM +0100, Carlos Rodrigues wrote:

Hi,

I don't know if this a too basic question to ask here, or the
proper
place, but here it goes:

I've been chasing some weird (to me) behavior with the targeted
policy
on a VM running nginx as a reverse proxy. What happens is that the
"httpd_can_network_connect" boolean needs to be enabled for nginx
to
be able to reach its upstream servers. So far, so good.

However, if the upsteam server happens to be listening in one of
the
"http_port_t" ports, "httpd_can_network_connect" isn't needed
because
the "httpd_graceful_shutdown" (default enabled) provides the
required
allow rule ("name_connect").

This seems strange to me. Is this supposed to be like this? I would
expect nginx to be totally unable to establish outbound connections
by
default.

Best regards,

Carlos Rodrigues

PS: I just spent a few hours on this, wondering why one machine
needed
"httpd_can_network_connect" and another did not. I guess I've
mostly
been setting up reverse proxies for "http_port_t" upstreams on
CentOS
all this time...


I think the "httpd_graceful_shutdown" is an apache thing (probably
for "apachectl graceful-stop"). However I cannot reproduce this
behavior with httpd-2.4.27-4.fc27.


Hmm...neither can I; seemingly apachectl graceful-stop works without
requiring this boolean anymore.  So maybe it can be disabled by default
and removed at some point in Fedora policy?



Would be nice if we would be able to confirm this with the apache maintainer 
before jumping to conclusions.



I had a discussion with apache maintainer in Fedora and he confirmed 
that this boolean is no longer needed in Fedora 27 or higher. Adding him 
to CC.


I see that in refpolicy, default value of httpd_graceful_shutdown is 
off, so we need to fix it only in Fedora distro policy. I'll prepare the 
patch.


Lukas.

--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.

Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute

2017-10-03 Thread Lukas Vrabec 

On 08/02/2017 08:59 PM, Stephen Smalley wrote:

On Wed, 2017-08-02 at 18:35 +0200, Dominick Grift wrote:

On Wed, Aug 02, 2017 at 04:41:00PM +0100, Carlos Rodrigues wrote:

Hi,

I don't know if this a too basic question to ask here, or the
proper
place, but here it goes:

I've been chasing some weird (to me) behavior with the targeted
policy
on a VM running nginx as a reverse proxy. What happens is that the
"httpd_can_network_connect" boolean needs to be enabled for nginx
to
be able to reach its upstream servers. So far, so good.

However, if the upsteam server happens to be listening in one of
the
"http_port_t" ports, "httpd_can_network_connect" isn't needed
because
the "httpd_graceful_shutdown" (default enabled) provides the
required
allow rule ("name_connect").

This seems strange to me. Is this supposed to be like this? I would
expect nginx to be totally unable to establish outbound connections
by
default.

Best regards,

Carlos Rodrigues

PS: I just spent a few hours on this, wondering why one machine
needed
"httpd_can_network_connect" and another did not. I guess I've
mostly
been setting up reverse proxies for "http_port_t" upstreams on
CentOS
all this time...


I think the "httpd_graceful_shutdown" is an apache thing (probably
for "apachectl graceful-stop"). However I cannot reproduce this
behavior with httpd-2.4.27-4.fc27.


Hmm...neither can I; seemingly apachectl graceful-stop works without
requiring this boolean anymore.  So maybe it can be disabled by default
and removed at some point in Fedora policy?



Same here, I cannot reproduce it or evoke any AVC using apachectl 
command. I'm using httpd-2.4.27-12.fc28.x86_64. I'll contact apache 
developers but I believe we can switch default value of boolean 
httpd_graceful_shutdown to OFF.


Lukas.

--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.