Re: ANN: SELinux userspace 2.7-rc2 release

2017-06-19 Thread Jason Zaman 
On Mon, Jun 19, 2017 at 01:06:10PM -0400, Stephen Smalley wrote:
> On Sun, 2017-06-18 at 15:32 +0800, Jason Zaman wrote:
> > There is a bug that needs to be fixed before the final release:
> > https://bugs.gentoo.org/show_bug.cgi?id=621762
> > 
> > I think the fix is just add override in utils/Makefile to the LDLIBS
> > and
> > LDFLAGS bits. I'm not sure I'll have time to get around to testing
> > it so just wanted to let you know before the final release.
> 
> I wondering if we should actually revert
> fcb5d5cc721187b3e3a19b44155d5b824d7be7e6, at least wrt removal of -L/-
> I.  This seems to have broken usage of DESTDIR (except from top-level,
> via 9a7763e18604c4649ff67ea6d43a730f90311592, which doesn't help people
> using the individual tar balls.  And it seems like many package recipes
> are relying on make DESTDIR= to work as expected.

Thats the thing tho, DESTDIR is not supposed to affect compilation at
all. it should only affect where things are installed to. lots of other
things get confused if that changes. DESTDIR is for when rpm or portage
or whatever want to keep track of all the files installed by a package
before merging into the real / so it can uninstall them all. If you
want to do like a prefix install into /home/bin or whatever then i think
the variable is SYSROOT or something like that.

building should technically be done something like:
passing DESTDIR when you do the actual compilation bits isnt right.

# portage or rpm's building thing or whatever do this automatically
export CC CFLAGS LDLFAGS etc
make all
make DESTDIR="/wherever" install
cd /wherever/
tar cf libselinux.tar ./

https://www.gnu.org/prep/standards/html_node/DESTDIR.html
"DESTDIR should be supported only in the install* and uninstall*
targets, as those are the only targets where it is useful."

-- Jason

Re: BINDIR/SBINDIR/... variables in Makefiles

2017-06-19 Thread Jason Zaman 
On Mon, Jun 19, 2017 at 03:50:26PM -0400, Stephen Smalley wrote:
> On Sat, 2017-06-17 at 15:55 +0200, Nicolas Iooss wrote:
> > Hello,
> > 
> > While updating packages for SELinux userspace 2.7-rc2 release, I
> > noticed there are still some inconsistencies in the Makefile
> > variables
> > related to bin and sbin directories. A quick search (with find .
> > -name
> > Makefile -exec cat {} + |grep '^[A-Z_]*BINDIR' |sort -u) shows:
> > 
> > BINDIR=$(PREFIX)/bin
> > BINDIR ?= $(PREFIX)/bin
> > BINDIR ?= $(PREFIX)/sbin
> > SBINDIR ?= $(DESTDIR)/sbin
> > SBINDIR ?= $(PREFIX)/sbin
> > USRSBINDIR ?= $(PREFIX)/sbin
> > 
> > In the coming days I will not have time to write and test patches in
> > order to make these variables more consistent. I am therefore sending
> > this message in case someone would want to fix these inconsistencies
> > before the 2.7 release.
> 
> I guess the question is do we need to still support distributions that
> do not enable usrmerge?

Yes please, Gentoo hasnt done usrmerge officially (yet?). You can of
course do usrmerge on gentoo but its not the default and since we're a
rolling distro even if/when we do switch we'll likely have to support
unmerged for quite a long time since there isnt a complete re-install on
new releases.

Although, there is still inconsistency in the naming which could perhaps
be fixed. one of them up there has BINDIR?=../sbin so should technically
be called SBINDIR i guess.

-- Jason
> 
> If so, then the difference is meaningful, and changing all SBINDIR
> instances to be either $(PREFIX)/sbin or $(DESTDIR)/sbin could create
> breakage.  Originally I was thinking we should convert them all to
> $(PREFIX)/sbin (and kill the load_policy symlink) and just drop
> USRSBINDIR entirely, since the majority of cases are already using that
> definition and in the usrmerge case it will correspond to the real
> path.  This would however break fixfiles (unless we also update it to
> specify /usr/sbin/{setfiles,restorecon}) and the make relabel targets
> in the selinux Makefiles (unless we update them all to specify
> /usr/sbin/restorecon) on non-usrmerge distributions.  More importantly,
> it would prevent running fixfiles, setfiles, and restorecon before /usr
> is mounted on non-usrmerge distributions, which could be problematic
> for e.g. autorelabel, invocation of restorecon from init scripts, etc.
> 
> Converting them all to $(DESTDIR)/sbin doesn't seem beneficial, as that
> would end up installing far more utilities into /sbin that aren't
> actually needed before /usr is mounted.
> 
> So, if non-usrmerge still matters, we probably can't make them
> consistent.  If it doesn't matter, then I'd go with the first option
> above.
> 
> > By the way, I noticed a few things in the RC that may be worth
> > mentioning in the final release announcement:
> > * libsemanage no longer needs ustr.
> > * libselinux/utils Makefile now uses USRSBINDIR instead of USRBINDIR
> > (since commit 055d14a99a84 ("libselinux/utils: do not create an empty
> > /sbin directory")).
> > * Some packages (libselinux, checkpolicy, selinux-python,
> > semodule-utils and mcstrans) require LIBSEPOLA to the set to the
> > absolute path to libsepol.a when building with DESTDIR set.
> 
> Thanks, will add to the release notes.
>

[PATCH] selinux: Assign proper class to PF_UNIX/SOCK_RAW sockets

2017-06-19 Thread Luis Ressel 
For PF_UNIX, SOCK_RAW is synonymous with SOCK_DGRAM (cf.
net/unix/af_unix.c). This is a tad obscure, but libpcap uses it.

Signed-off-by: Luis Ressel 
Acked-by: Stephen Smalley 
---
 security/selinux/hooks.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 819fd6858b49..1a331fba4a3c 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1275,6 +1275,7 @@ static inline u16 socket_type_to_security_class(int 
family, int type, int protoc
case SOCK_SEQPACKET:
return SECCLASS_UNIX_STREAM_SOCKET;
case SOCK_DGRAM:
+   case SOCK_RAW:
return SECCLASS_UNIX_DGRAM_SOCKET;
}
break;
-- 
2.13.1

Re: [PATCH] selinux: Assign proper class to PF_UNIX/SOCK_RAW sockets

2017-06-19 Thread Stephen Smalley 
On Sun, 2017-06-18 at 23:45 +0200, Luis Ressel wrote:
> For PF_UNIX, SOCK_RAW is synonymous with SOCK_DGRAM (cf.
> net/unix/af_unix.c). This is a tad obscure, but libpcap uses it.

No Signed-off-by?

Feel free to add my:
Acked-by: Stephen Smalley 

> ---
>  security/selinux/hooks.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 819fd6858b49..1a331fba4a3c 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1275,6 +1275,7 @@ static inline u16
> socket_type_to_security_class(int family, int type, int protoc
>   case SOCK_SEQPACKET:
>   return SECCLASS_UNIX_STREAM_SOCKET;
>   case SOCK_DGRAM:
> + case SOCK_RAW:
>   return SECCLASS_UNIX_DGRAM_SOCKET;
>   }
>   break;

[RFC][PATCH] Make BINDIR/SBINDIR/USRSBINDIR definition and usage consistent.

2017-06-19 Thread Stephen Smalley 
As reported by Nicolas Iooss, there are still some inconsistencies
in Makefile variables related to bin and sbin directories.  Fix them.

Before:
$ find . -name Makefile -exec cat {} + |grep '^[A-Z_]*BINDIR' |sort -u
BINDIR=$(PREFIX)/bin
BINDIR ?= $(PREFIX)/bin
BINDIR ?= $(PREFIX)/sbin
SBINDIR ?= $(DESTDIR)/sbin
SBINDIR ?= $(PREFIX)/sbin
USRSBINDIR ?= $(PREFIX)/sbin

After:
$ find . -name Makefile -exec cat {} + | grep '^[A-Z_]*BINDIR' | sort -u
BINDIR ?= $(PREFIX)/bin
SBINDIR ?= $(PREFIX)/sbin

For systems without usrmerge, this changes the default install
location for fixfiles, setfiles, restorecon, restorecon_xattr,
and mcstransd from /sbin to /usr/sbin, and drops the symbolic
link from /usr/sbin/load_policy to /sbin/load_policy.  It
also updates fixfiles with the new paths for setfiles and
restorecon, and drops the absolute path for make relabel
targets, just relying on PATH to be set appropriately.

Reported-by: Nicolas Iooss 
Signed-off-by: Stephen Smalley 
---
 checkpolicy/Makefile | 4 ++--
 checkpolicy/test/Makefile| 2 +-
 libselinux/src/Makefile  | 2 +-
 libselinux/utils/Makefile| 6 +++---
 libsemanage/src/Makefile | 2 +-
 libsepol/src/Makefile| 2 +-
 mcstrans/src/Makefile| 2 +-
 mcstrans/utils/Makefile  | 6 +++---
 policycoreutils/load_policy/Makefile | 7 ++-
 policycoreutils/newrole/Makefile | 2 +-
 policycoreutils/run_init/Makefile| 2 +-
 policycoreutils/scripts/Makefile | 3 +--
 policycoreutils/scripts/fixfiles | 4 ++--
 policycoreutils/secon/Makefile   | 2 +-
 policycoreutils/setfiles/Makefile| 2 +-
 python/chcat/Makefile| 3 +--
 python/sepolicy/sepolicy/templates/script.py | 2 +-
 restorecond/Makefile | 2 +-
 18 files changed, 25 insertions(+), 30 deletions(-)

diff --git a/checkpolicy/Makefile b/checkpolicy/Makefile
index 68e11f2..658b02a 100644
--- a/checkpolicy/Makefile
+++ b/checkpolicy/Makefile
@@ -53,8 +53,8 @@ install: all
install -m 644 checkmodule.8 $(MANDIR)/man8
 
 relabel: install
-   /sbin/restorecon $(BINDIR)/checkpolicy
-   /sbin/restorecon $(BINDIR)/checkmodule
+   restorecon $(BINDIR)/checkpolicy
+   restorecon $(BINDIR)/checkmodule
 
 clean:
-rm -f $(TARGETS) $(CHECKPOLOBJS) $(CHECKMODOBJS) y.tab.c y.tab.h 
lex.yy.c
diff --git a/checkpolicy/test/Makefile b/checkpolicy/test/Makefile
index 0a31c5e..59fa446 100644
--- a/checkpolicy/test/Makefile
+++ b/checkpolicy/test/Makefile
@@ -2,7 +2,7 @@
 # Makefile for building the dispol program
 #
 PREFIX ?= $(DESTDIR)/usr
-BINDIR=$(PREFIX)/bin
+BINDIR ?= $(PREFIX)/bin
 LIBDIR ?= $(PREFIX)/lib
 INCLUDEDIR ?= $(PREFIX)/include
 LIBSEPOLA ?= $(LIBDIR)/libsepol.a
diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 4306dd0..bb91465 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -196,7 +196,7 @@ install-rubywrap: rubywrap
install -m 755 $(SWIGRUBYSO) $(RUBYINSTALL)/selinux.so
 
 relabel:
-   /sbin/restorecon $(SHLIBDIR)/$(LIBSO)
+   restorecon $(SHLIBDIR)/$(LIBSO)
 
 clean-pywrap:
-rm -f $(SWIGLOBJ) $(SWIGSO) $(AUDIT2WHYLOBJ) $(AUDIT2WHYSO)
diff --git a/libselinux/utils/Makefile b/libselinux/utils/Makefile
index 474ee95..843b0e7 100644
--- a/libselinux/utils/Makefile
+++ b/libselinux/utils/Makefile
@@ -1,7 +1,7 @@
 # Installation directories.
 PREFIX ?= $(DESTDIR)/usr
 LIBDIR ?= $(PREFIX)/lib
-USRSBINDIR ?= $(PREFIX)/sbin
+SBINDIR ?= $(PREFIX)/sbin
 INCLUDEDIR ?= $(PREFIX)/include
 
 OS ?= $(shell uname)
@@ -63,8 +63,8 @@ sefcontext_compile: sefcontext_compile.o ../src/regex.o
 all: $(TARGETS)
 
 install: all
-   -mkdir -p $(USRSBINDIR)
-   install -m 755 $(TARGETS) $(USRSBINDIR)
+   -mkdir -p $(SBINDIR)
+   install -m 755 $(TARGETS) $(SBINDIR)
 
 clean:
rm -f $(TARGETS) *.o *~
diff --git a/libsemanage/src/Makefile b/libsemanage/src/Makefile
index f01385c..4ed95f7 100644
--- a/libsemanage/src/Makefile
+++ b/libsemanage/src/Makefile
@@ -155,7 +155,7 @@ install-rubywrap: rubywrap
install -m 755 $(SWIGRUBYSO) $(RUBYINSTALL)/semanage.so
 
 relabel:
-   /sbin/restorecon $(LIBDIR)/$(LIBSO)
+   restorecon $(LIBDIR)/$(LIBSO)
 
 clean: 
-rm -f $(LIBPC) $(OBJS) $(LOBJS) $(LIBA) $(LIBSO) $(SWIGLOBJ) $(SWIGSO) 
$(SWIGRUBYSO) $(TARGET) conf-parse.c conf-parse.h conf-scan.c *.o *.lo *~
diff --git a/libsepol/src/Makefile b/libsepol/src/Makefile
index 819d261..e39244d 100644
--- a/libsepol/src/Makefile
+++ b/libsepol/src/Makefile
@@ -89,7 +89,7 @@ install: all
$(LN) -sf --relative $(SHLIBDIR)/$(LIBSO) $(LIBDIR)/$(TARGET)
 
 relabel:
-   /sbin/restorecon $(SHLIBDIR)/$(LIBSO)
+   restorecon $(SHLIBDIR)/$(LIBSO)
 
 clean: 
-rm -f $(LIBPC) $(LIBMAP)

Re: BINDIR/SBINDIR/... variables in Makefiles

2017-06-19 Thread Stephen Smalley 
On Sat, 2017-06-17 at 15:55 +0200, Nicolas Iooss wrote:
> Hello,
> 
> While updating packages for SELinux userspace 2.7-rc2 release, I
> noticed there are still some inconsistencies in the Makefile
> variables
> related to bin and sbin directories. A quick search (with find .
> -name
> Makefile -exec cat {} + |grep '^[A-Z_]*BINDIR' |sort -u) shows:
> 
> BINDIR=$(PREFIX)/bin
> BINDIR ?= $(PREFIX)/bin
> BINDIR ?= $(PREFIX)/sbin
> SBINDIR ?= $(DESTDIR)/sbin
> SBINDIR ?= $(PREFIX)/sbin
> USRSBINDIR ?= $(PREFIX)/sbin
> 
> In the coming days I will not have time to write and test patches in
> order to make these variables more consistent. I am therefore sending
> this message in case someone would want to fix these inconsistencies
> before the 2.7 release.

I guess the question is do we need to still support distributions that
do not enable usrmerge?

If so, then the difference is meaningful, and changing all SBINDIR
instances to be either $(PREFIX)/sbin or $(DESTDIR)/sbin could create
breakage.  Originally I was thinking we should convert them all to
$(PREFIX)/sbin (and kill the load_policy symlink) and just drop
USRSBINDIR entirely, since the majority of cases are already using that
definition and in the usrmerge case it will correspond to the real
path.  This would however break fixfiles (unless we also update it to
specify /usr/sbin/{setfiles,restorecon}) and the make relabel targets
in the selinux Makefiles (unless we update them all to specify
/usr/sbin/restorecon) on non-usrmerge distributions.  More importantly,
it would prevent running fixfiles, setfiles, and restorecon before /usr
is mounted on non-usrmerge distributions, which could be problematic
for e.g. autorelabel, invocation of restorecon from init scripts, etc.

Converting them all to $(DESTDIR)/sbin doesn't seem beneficial, as that
would end up installing far more utilities into /sbin that aren't
actually needed before /usr is mounted.

So, if non-usrmerge still matters, we probably can't make them
consistent.  If it doesn't matter, then I'd go with the first option
above.

> By the way, I noticed a few things in the RC that may be worth
> mentioning in the final release announcement:
> * libsemanage no longer needs ustr.
> * libselinux/utils Makefile now uses USRSBINDIR instead of USRBINDIR
> (since commit 055d14a99a84 ("libselinux/utils: do not create an empty
> /sbin directory")).
> * Some packages (libselinux, checkpolicy, selinux-python,
> semodule-utils and mcstrans) require LIBSEPOLA to the set to the
> absolute path to libsepol.a when building with DESTDIR set.

Thanks, will add to the release notes.

Re: ANN: SELinux userspace 2.7-rc2 release

2017-06-19 Thread Stephen Smalley 
On Sun, 2017-06-18 at 15:32 +0800, Jason Zaman wrote:
> There is a bug that needs to be fixed before the final release:
> https://bugs.gentoo.org/show_bug.cgi?id=621762
> 
> I think the fix is just add override in utils/Makefile to the LDLIBS
> and
> LDFLAGS bits. I'm not sure I'll have time to get around to testing
> it so just wanted to let you know before the final release.

I wondering if we should actually revert
fcb5d5cc721187b3e3a19b44155d5b824d7be7e6, at least wrt removal of -L/-
I.  This seems to have broken usage of DESTDIR (except from top-level,
via 9a7763e18604c4649ff67ea6d43a730f90311592, which doesn't help people
using the individual tar balls.  And it seems like many package recipes
are relying on make DESTDIR= to work as expected.

Re: Collecting ideas for audit2allow improvement

2017-06-19 Thread Simon Sekidde 


- Original Message -
> From: "Daniel Walsh" 
> To: selinux@tycho.nsa.gov
> Sent: Monday, June 19, 2017 11:45:53 AM
> Subject: Re: Collecting ideas for audit2allow improvement
> 
> On 06/16/2017 12:08 PM, Dominick Grift wrote:
> > On Fri, Jun 16, 2017 at 08:21:25AM -0400, Daniel Walsh wrote:
> >> On 06/14/2017 10:47 AM, Dominick Grift wrote:
> >>> On Wed, Jun 14, 2017 at 04:35:41PM +0200, Dominick Grift wrote:
>  On Wed, Jun 14, 2017 at 10:30:25AM -0400, Stephen Smalley wrote:
> > On Wed, 2017-06-14 at 09:01 -0400, Jan Zarsky wrote:
> >> Hi,
> >>
> >> I would like to improve SELinux audit2allow tool as my bachelor
> >> thesis.
> >> I collected ideas from my colleagues from RedHat SELinux team and I
> >> would also
> >> like to hear your ideas - what would you improve to make audit2allow
> >> smarter or
> >> easier to use.
> >>
> >> Ideas collected so far:
> >>
> >> * offer dac_read_search when sufficient instead of dac_override
> >>   (see )
> > The hard part here is knowing when it is sufficient.  Might require
> > further kernel patches to get to the point where it is completely
> > unambiguous from the audit messages alone.  You could perhaps default
> > to only allowing dac_read_search and only allow dac_override if you see
> > that dac_read_search is already allowed and you are still getting a
> > dac_override denial.
>  This should not be an issue anymore. Becuase now (linux v4.12)
>  dac_read_search is first checked
>  so translating a rule for dac_read_search will always be the most secure
>  option. It might not be enough but youll notice if it isnt. Just rerun
>  it again and you'll end up with dac_override if needed.
> 
> >> * offer multiple solutions to a problem (example: 1) add allow
> >> rule
> >> for
> >>   execute + execute_no_trans or 2) add allow rule for execute
> >>   + type_transition rule)
> > Is this type_transition to an existing type that already exists, or
> > defining a new type and transitioning to it, or both?  Generating new
> > domains and types dynamically is one of the major gaps in current
> > audit2allow, and to date has only been supported in separate tools like
> > sepolicy generate.
>  One should be extremely careful here. "execute" does not automatically
>  imply "execute_no_trans". That assumption can lead to disaster
>  (https://www.cvedetails.com/cve/CVE-2015-1815/)
> >> * interactive mode: ask questions and choose best solution
> >> * warn when solution touches trusted computing base (rules you
> >> should not be
> >>   adding)
> >> * suggest alternate labels for content, example: httpd_t not
> >> allowed to write
> >>   to user_home_t, might suggest that changing the label to
> >>   httpd_user_content_t
> > This seems more along the lines of what setroubleshoot does, and tends
> > to be policy-specific. We need to preserve the usability of audit2allow
> > for other policies (e.g. Android, DSSP), so any policy-specific logic
> > needs to be encapsulated, configuration-driven, and optional.
>  setroubleshoot is not smart enough to suggest httpd_user_content_t,
>  instead it suggest you allow full access to /home/* by toggling the
>  boolean that grants access to user home content.
> 
>  I know this from experience. There was a bug in fedora's
>  apache_user_content_template for more than a year and hardly anyone
>  noticed it, probably because setroubleshoot would have just suggested
>  you allow full access to user home content.
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1457406
> >> I actually think the suggest a accessible type is  the best improvement.
> >> audit2allow has defaulted for years to suggesting adding allow rules,
> >> usually the worst solution.  Later we added boolean support, which was
> >> better but as you point out the not a great solution in a lot of cases.
> > The "best" improvement. I agree, but that say's more about the overal state
> > of things than about the quality of this particular improvement.
> >
> > The guy in the tweet was overwhelmed and intimidated by the large list of
> > "accessible" types returned by setroubleshoot (and audit2allow would
> > probably do the same)
> > Also things arent as simple, its not just about "what type grants the
> > access needed to my domain". Other domains access to that type should also
> > be considered.
> Which is why I suggested we filter it down to a list that has the same
> prefix.  Also I think we should at least stick in the beginning to
> permissions that can effect the content of data, rather then just reveal
> the content.
> 
> write, append, add_name unlink setattr, remove_name rmdir link create ...
> 
> I think

Re: Collecting ideas for audit2allow improvement

2017-06-19 Thread Daniel Walsh 

On 06/16/2017 12:08 PM, Dominick Grift wrote:

On Fri, Jun 16, 2017 at 08:21:25AM -0400, Daniel Walsh wrote:

On 06/14/2017 10:47 AM, Dominick Grift wrote:

On Wed, Jun 14, 2017 at 04:35:41PM +0200, Dominick Grift wrote:

On Wed, Jun 14, 2017 at 10:30:25AM -0400, Stephen Smalley wrote:

On Wed, 2017-06-14 at 09:01 -0400, Jan Zarsky wrote:

Hi,

I would like to improve SELinux audit2allow tool as my bachelor
thesis.
I collected ideas from my colleagues from RedHat SELinux team and I
would also
like to hear your ideas - what would you improve to make audit2allow
smarter or
easier to use.

Ideas collected so far:

* offer dac_read_search when sufficient instead of dac_override
  (see )

The hard part here is knowing when it is sufficient.  Might require
further kernel patches to get to the point where it is completely
unambiguous from the audit messages alone.  You could perhaps default
to only allowing dac_read_search and only allow dac_override if you see
that dac_read_search is already allowed and you are still getting a
dac_override denial.

This should not be an issue anymore. Becuase now (linux v4.12) dac_read_search 
is first checked
so translating a rule for dac_read_search will always be the most secure 
option. It might not be enough but youll notice if it isnt. Just rerun it again 
and you'll end up with dac_override if needed.


* offer multiple solutions to a problem (example: 1) add allow rule
for
  execute + execute_no_trans or 2) add allow rule for execute
  + type_transition rule)

Is this type_transition to an existing type that already exists, or
defining a new type and transitioning to it, or both?  Generating new
domains and types dynamically is one of the major gaps in current
audit2allow, and to date has only been supported in separate tools like
sepolicy generate.

One should be extremely careful here. "execute" does not automatically imply 
"execute_no_trans". That assumption can lead to disaster 
(https://www.cvedetails.com/cve/CVE-2015-1815/)

* interactive mode: ask questions and choose best solution
* warn when solution touches trusted computing base (rules you
should not be
  adding)
* suggest alternate labels for content, example: httpd_t not
allowed to write
  to user_home_t, might suggest that changing the label to
  httpd_user_content_t

This seems more along the lines of what setroubleshoot does, and tends
to be policy-specific. We need to preserve the usability of audit2allow
for other policies (e.g. Android, DSSP), so any policy-specific logic
needs to be encapsulated, configuration-driven, and optional.

setroubleshoot is not smart enough to suggest httpd_user_content_t, instead it 
suggest you allow full access to /home/* by toggling the boolean that grants 
access to user home content.

I know this from experience. There was a bug in fedora's 
apache_user_content_template for more than a year and hardly anyone noticed it, 
probably because setroubleshoot would have just suggested you allow full access 
to user home content.

https://bugzilla.redhat.com/show_bug.cgi?id=1457406

I actually think the suggest a accessible type is  the best improvement.
audit2allow has defaulted for years to suggesting adding allow rules,
usually the worst solution.  Later we added boolean support, which was
better but as you point out the not a great solution in a lot of cases.

The "best" improvement. I agree, but that say's more about the overal state of 
things than about the quality of this particular improvement.

The guy in the tweet was overwhelmed and intimidated by the large list of 
"accessible" types returned by setroubleshoot (and audit2allow would probably 
do the same)
Also things arent as simple, its not just about "what type grants the access needed 
to my domain". Other domains access to that type should also be considered.
Which is why I suggested we filter it down to a list that has the same 
prefix.  Also I think we should at least stick in the beginning to 
permissions that can effect the content of data, rather then just reveal 
the content.


write, append, add_name unlink setattr, remove_name rmdir link create ...

I think anything we can do to making it easier for the user to get a 
proper type, would be really helpful.

Most AVC's are caused by mislabeled files or processes.  Having audit2allow
attempt to examine the policy and figure out which types would have been
allowed with some simple sorting rules might be a big improvement.

audit2allow INHO shouldnt "examine" the policy (at least not in any significant 
way) because it cannot do it right. audit2allow should just stick with the basics + 
audit2why.

audit2why is the only functionality that works reasonably well. provided that some of the 
more recent "improvements" to audit2why get removed.
audit2why does nothing to reveal the crutch of the problem, SELinux is a 
Labeling system, if things go wrong, most of