[nicolas.io...@m4x.org: Re: Bash 5 change in behavior and SELinux]
I noticed that Bash5 requires some additional permissions that I found
questionable.
Mostly the listing of / and /home
I am wondering whether there is a way to avoid the requirement for above
permissions.
After some digging with the help of the community we came up with the following
analysis:
- Forwarded message from Nicolas Iooss -
Date: Sun, 24 Feb 2019 21:32:13 +0100
From: Nicolas Iooss
To: Dominick Grift
Cc: seli...@vger.kernel.org
Subject: Re: Bash 5 change in behavior and SELinux
On Sun, Feb 24, 2019 at 7:37 PM Dominick Grift
wrote:
>
> On Sun, Feb 24, 2019 at 07:17:33PM +0100, Nicolas Iooss wrote:
> > On Sun, Feb 24, 2019 at 6:39 PM Dominick Grift
> > 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:
>
> type=SYSCALL msg=audit(02/24/2019 19:33:13.924:18121) : arch=x86_64
> syscall=openat success=yes exit=3 a0=0xff9c a1=0x561168c81e40
> a2=O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC a3=0x0 items=1 ppid=2270
> pid=27900 auid=kcinimod uid=kcinimod gid=kcinimod euid=kcinimod suid=kcinimod
> fsuid=
>
> >
> > * The bash version you are using is not 5.0.2-1.fc30. Which one are you
> > using?
>
> it is 5.0.2-1, downgrading to 4.4.23-7 fixes it
>
> > * 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?
>
> Yes 4 is fine
>
> > * Or it might come from a bash dependency (like readline).
>
> Does not look like it: just downgrading "bash" fixes it
I managed to reproduce the issue. Here are the steps I followed:
* Download a Fedora 30 (Rawhide) live CD from
https://dl.fedorapr
Re: [nicolas.io...@m4x.org: Re: Bash 5 change in behavior and SELinux]
Simple test:
21:54 So, the simple testcase, without SELinux : |
21:54 - sudo chmod a-r /home |
21:54 - cd $HOME |
21:54 - touch a.test |
21:54 - rm ~/*.test |
21:54 => rm: cannot remove '/home/liveuser/*.test': No |
such file or directory |
21:54 and a.test is still there
On Sun, Feb 24, 2019 at 09:50:41PM +0100, Dominick Grift wrote:
> I noticed that Bash5 requires some additional permissions that I found
> questionable.
>
> Mostly the listing of / and /home
>
> I am wondering whether there is a way to avoid the requirement for above
> permissions.
>
> After some digging with the help of the community we came up with the
> following analysis:
>
> - Forwarded message from Nicolas Iooss -
>
> Date: Sun, 24 Feb 2019 21:32:13 +0100
> From: Nicolas Iooss
> To: Dominick Grift
> Cc: seli...@vger.kernel.org
> Subject: Re: Bash 5 change in behavior and SELinux
>
> On Sun, Feb 24, 2019 at 7:37 PM Dominick Grift
> wrote:
> >
> > On Sun, Feb 24, 2019 at 07:17:33PM +0100, Nicolas Iooss wrote:
> > > On Sun, Feb 24, 2019 at 6:39 PM Dominick Grift
> > > 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:
> >
> > type=SYSCALL msg=audit(02/24/2019 19:33:13.924:18121) : arch=x86_64
> > syscall=ope
