Re: Bash 5 change in behavior and SELinux

[Nicolas Iooss <nicolas.iooss@m4x.org>]

On Sun, Feb 24, 2019 at 6:39 PM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> On Sun, Feb 24, 2019 at 05:59:19PM +0100, Dominick Grift wrote:
> > Recently Bash-5 appeared in the Fedora repositories and i instantly noticed an inpleasant change (for the record: this did not happen before):
>
> I suppose this is just a "feature" or a "bug" in Bash-5 and that i will just have to deal with it. Just seems a bit unnecessary access to me.
>
> >
> > [kcinimod@brutus ~]$ touch mytest1.test
> > [kcinimod@brutus ~]$ rm ~/*.test
> > rm: cannot remove '/home/kcinimod/*.test': No such file or directory
> > [kcinimod@brutus ~]$ rm ~/mytest1.test
> > [kcinimod@brutus ~]$ echo $?
> > 0
> >
> > After running `semodule -DB` the following AVC denials surfaced:
> >
> > avc:  denied  { read } for  pid=2178 comm="bash" name="/" dev="dm-3" ino=2 scontext=wheel.id:wheel.role:wheel.subj:s0 tcontext=sys.id:sys.role:files.home.file:s0 tclass=dir permissive=1
> > avc:  denied  { read } for  pid=2178 comm="bash" name="/" dev="dm-1" ino=2 scontext=wheel.id:wheel.role:wheel.subj:s0 tcontext=sys.id:sys.role:fs.rootfs.fs:s0 tclass=dir permissive=1

[For other readers: these are the labels of /home and /, the parent
directories of /home/kcinimod/]

> > So I took to #bash and they told me:
> >
> > 17:43 <_abc_> grift: that is exactly what you see on android and is
> >               a direct result of the missing x bit equivalent in
> >               the selinux policy
> >
> > 17:44 <_abc_> grift: rephrased: globbing the * requires the x bit
> >               set
> > 17:44 <_abc_> (it's equivalent in selinux policy)
> >
> > So why does this show up as a "read"? Its allowed to "search" "/" and "/home", but since Bash 5 this no longer is enough.
> >
> > Scripts break everywhere because of this

What is the syscall associated with the avc entries? This would help
finding in bash's source what triggered this behavior.
I tried to reproduce your commands in Arch Linux (bash package
5.0.0-1) or Fedora 30 (bash package 5.0.2-1.fc30 for x86_64) by using
strace on bash and watching the syscalls, but nothing stood out: I see
an "openat(AT_FDCWD, "/home/kcinimod/",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3" followed by calls to
"getdents64(3, ...)", which are like expected. This could be due to
several things:

* The bash version you are using is not 5.0.2-1.fc30. Which one are you using?
* It might come from a kernel bug (which would open the parent
directories with read access). That would be really strange, but only
to be sure: is bash 4 working fine when you downgrade bash package
while keeping the same kernel?
* Or it might come from a bash dependency (like readline).

> >
> > Here is an strace:
> >
> > execve("/usr/bin/rm", ["rm", "/home/kcinimod/*.test"], 0x7ffd4a604e68 /* 33 vars */) = 0

By the way, using strace on rm was not useful because it only showed
that it was been called with the raw (unexpanded) parameter. Could you
run the same commands of your test-case in a "strace -s1024 -o
strace-bash.log bash" and share the resulting strace-bash.log file?

Thanks,
Nicolas