clisp-devel

Re: libffcall and selinux

[<don...@is...>]

Bruno Haible writes:

 > Yes, nearly everyone on Linux/x86_64 is seeing this (or a similar)
 > crash.

When did this start?

 > > make -k check also shows
 > >  > form: (nth-prime 150)
 > > 
 > > *** - Program stack overflow. RESET
 > 
 > Now this means that the default stack size is quite small. What's
 > the result of

 > $ ulimit -a | grep stack
 > ? For me, it's:
 > stack size              (kbytes, -s) 8192

the current limit (8515) seems to be as high as I can set it.
You consider that to be small?  

 > > Let me know if I can do anything else useful with this VM before 
 > > I turn it off.
 > 
 > Yes, it would be useful to enable SELinux checks (at least those
 > that smell like related to "restricted mprotect" or like "write xor
 > execute" or similar, and see how clisp behaves with these checks
 > enabled.

I don't understand selinux very well.
And I'm also not sure I understand what you're looking for, but
here's an attempt.  Let me know if it gives you any better ideas.

It seems like there are all sorts of policies that one COULD write,
one that is installed in a given distribution, and the one that comes
with Fedora-Server-dvd-x86_64-25-1.3 is the one I initially tested.
That policy does seem to me to have some strange features, though.
Just looking at 
 getsebool -a | grep selinuxuser
I see
 selinuxuser_execheap --> off
which is what causes the AVC denial in configuring ffcall.
(I verified that by turning it on and redoing config.)

This is described as follows at
 https://mgrepl.fedorapeople.org/man_selinux/Fedora18/user.html

 If you want to allow unconfined executables to make their heap memory
 executable. Doing this is a really bad idea. Probably indicates a
 badly coded executable, but could indicate an attack. This executable
 should be reported in bugzilla, you must turn on the
 selinuxuser_execheap boolean.
 setsebool -P selinuxuser_execheap 1

However, getsebool also shows
 selinuxuser_execstack --> on

 If you want to allow unconfined executables to make their stack
 executable. This should never, ever be necessary. Probably indicates
 a badly coded executable, but could indicate an attack. This
 executable should be reported in bugzilla, you must turn on the
 selinuxuser_execstack boolean.
 setsebool -P selinuxuser_execstack 1

I don't understand why that one is on by default.
But when I turn it off and do make -k check for clisp I don't see
any AVC denials.

 selinuxuser_execmod --> on

 If you want to allow all unconfined executables to use libraries
 requiring text relocation that are not labeled textrel_shlib_t, you
 must turn on the selinuxuser_execmod boolean.
 setsebool -P selinuxuser_execmod 1 

I don't quite follow all that, but again, turning it off doesn't
cause any AVC dnials in clisp make -k check.

I don't see any booleans with protect (or even prot) in the name.

Re: libffcall and selinux

[Bruno H. <br...@cl...>]

Hi Don,

> Just looking at 
>  getsebool -a | grep selinuxuser
> I see
>  selinuxuser_execheap --> off
> which is what causes the AVC denial in configuring ffcall.
> (I verified that by turning it on and redoing config.)
> 
> This is described as follows at
>  https://mgrepl.fedorapeople.org/man_selinux/Fedora18/user.html
> 
>  If you want to allow unconfined executables to make their heap memory
>  executable. Doing this is a really bad idea. Probably indicates a
>  badly coded executable, but could indicate an attack. This executable
>  should be reported in bugzilla, you must turn on the
>  selinuxuser_execheap boolean.
>  setsebool -P selinuxuser_execheap 1
> 
> However, getsebool also shows
>  selinuxuser_execstack --> on
> 
>  If you want to allow unconfined executables to make their stack
>  executable. This should never, ever be necessary. Probably indicates
>  a badly coded executable, but could indicate an attack. This
>  executable should be reported in bugzilla, you must turn on the
>  selinuxuser_execstack boolean.
>  setsebool -P selinuxuser_execstack 1

Thanks for these pointers. I installed a RHEL 6 VM, then looked at how
these flags influence the libffcall configure tests, and modified libffcall
to bypass these configure tests in case of SELinux. Since the results
are dependent on flags that can change at runtime, the code better assumes
the worst possible result.

Bruno

Re: libffcall and selinux

[Vladimir T. <vtz...@gm...>]

On Fri, May 26, 2017 at 12:28 AM, Bruno Haible <br...@cl...> wrote:

> Hi Don,
>
> > May 25 12:10:41 localhost audit: ANOM_ABEND auid=0 uid=0 gid=0 ses=3
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=11356
> comm="lisp.run" exe="/home/don/hg/clisp/build-dir/lisp.run" sig=11
> > May 25 12:10:41 localhost kernel: lisp.run[11356]: segfault at
> b000000b1f1 ip 00000000004bdeb4 sp 00007ffd4d6b82f0 error 4 in
> lisp.run[400000+2c1000]
> > May 25 12:10:42 localhost abrt-hook-ccpp: Process 11356 (lisp.run) of
> user 0 killed by SIGSEGV - dumping core
> >
> > I'm guessing this is related to the problem you're now working on,
> > but not related to selinux.
>
> Yes, nearly everyone on Linux/x86_64 is seeing this (or a similar) crash.
>

OSX(x86_64) as well.
And again I'll emphasise I experience this only on non-ffi builds. It is
consistently reproducible - have to find time to go after it.

Re: libffcall and selinux

[<don...@is...>]

output from make check:

(STRINGP (WITH-OUTPUT-TO-STRING (S) (DESCRIBE NIL S)))
;; connecting to "http://clisp.org/impnotes/id-href.map"...connected...HTTP/1.1 200 OK...74,909 bytes
;; SYSTEM::GET-STRING-MAP(#<IO INPUT-BUFFERED SOCKET-STREAM CHARACTER clisp.org:80>)...Makefile:25: recipe for target 'tests' failed
make[1]: *** [tests] Segmentation fault (core dumped)

corresponding output in system log

 > > > May 25 12:10:41 localhost audit: ANOM_ABEND auid=0 uid=0 gid=0 ses=3
 > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=11356
 > > comm="lisp.run" exe="/home/don/hg/clisp/build-dir/lisp.run" sig=11
 > > > May 25 12:10:41 localhost kernel: lisp.run[11356]: segfault at
 > > b000000b1f1 ip 00000000004bdeb4 sp 00007ffd4d6b82f0 error 4 in
 > > lisp.run[400000+2c1000]
 > > > May 25 12:10:42 localhost abrt-hook-ccpp: Process 11356 (lisp.run) of
 > > user 0 killed by SIGSEGV - dumping core
 > > >
 > > > I'm guessing this is related to the problem you're now working on,
 > > > but not related to selinux.
 > >

 > On Fri, May 26, 2017 at 12:28 AM, Bruno Haible <br...@cl...> wrote:
 > 
 > > Yes, nearly everyone on Linux/x86_64 is seeing this (or a similar) crash.

Vladimir Tzankov writes:

 > OSX(x86_64) as well.
 > And again I'll emphasise I experience this only on non-ffi builds. It is
 > consistently reproducible - have to find time to go after it.

Then this one is different, cause it DOES include FFI:

[root@localhost build-dir]# full/lisp.run -M full/lispinit.mem
STACK size: 98238 [0x300000bfe00 0x30000000010]
...
Type :h and hit Enter for context help.

[1]> *features*
(:RAWSOCK :READLINE :REGEXP :WILDCARD :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP
 :CLISP :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER :LOGICAL-PATHNAMES :SOCKETS
 :GENERIC-STREAMS :SCREEN :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER
 :WORD-SIZE=64 :PC386 :UNIX)
[2]> 

Re: libffcall and selinux

[Bruno H. <br...@cl...>]

Hi Don,

>  > Yes, it would be useful to enable SELinux checks (at least those
>  > that smell like related to "restricted mprotect" or like "write xor
>  > execute" or similar, and see how clisp behaves with these checks
>  > enabled.
> ...
> However, getsebool also shows
>  selinuxuser_execstack --> on
> 
>  If you want to allow unconfined executables to make their stack
>  executable. This should never, ever be necessary. Probably indicates
>  a badly coded executable, but could indicate an attack. This
>  executable should be reported in bugzilla, you must turn on the
>  selinuxuser_execstack boolean.
>  setsebool -P selinuxuser_execstack 1

This looks like the one that may be related to libffcall.

If you can go on with experiments, the better.
If not, I will pursue this avenue further.

>  selinuxuser_execmod --> on
> 
>  If you want to allow all unconfined executables to use libraries
>  requiring text relocation that are not labeled textrel_shlib_t, you
>  must turn on the selinuxuser_execmod boolean.
>  setsebool -P selinuxuser_execmod 1 

clisp doesn't use this feature (it's x86 specific, and the Solaris linker
has produced errors for this situation already for years, IIRC).

Bruno

Re: libffcall and selinux

[<don...@is...>]

 > > However, getsebool also shows
 > >  selinuxuser_execstack --> on
 > > 
 > >  If you want to allow unconfined executables to make their stack
 > >  executable. This should never, ever be necessary. Probably indicates
 > >  a badly coded executable, but could indicate an attack. This
 > >  executable should be reported in bugzilla, you must turn on the
 > >  selinuxuser_execstack boolean.
 > >  setsebool -P selinuxuser_execstack 1
 > 
 > This looks like the one that may be related to libffcall.

No, libffcall was triggering execheap.  It still does in the
conftest, but that qualifies as intended behavior.

I've not yet seen any execstack complaints.

 > If you can go on with experiments, the better.
 > If not, I will pursue this avenue further.

I should probably read more about selinux anyway.

 > >  If you want to allow all unconfined executables to use libraries
 > >  requiring text relocation that are not labeled textrel_shlib_t, you
 > >  must turn on the selinuxuser_execmod boolean.
 > >  setsebool -P selinuxuser_execmod 1 
 > 
 > clisp doesn't use this feature (it's x86 specific, and the Solaris linker
 > has produced errors for this situation already for years, IIRC).

I've not seen any complaints about this one either.

So as far as I know so far, current clisp has no issues with selinux
on latest fedora.
(Plenty of other things do, though.)

Re: libffcall and selinux

[Bruno H. <br...@cl...>]

Hi Don,

>  > > However, getsebool also shows
>  > >  selinuxuser_execstack --> on
>  > > 
>  > >  If you want to allow unconfined executables to make their stack
>  > >  executable. This should never, ever be necessary. Probably indicates
>  > >  a badly coded executable, but could indicate an attack. This
>  > >  executable should be reported in bugzilla, you must turn on the
>  > >  selinuxuser_execstack boolean.
>  > >  setsebool -P selinuxuser_execstack 1
>  > 
>  > This looks like the one that may be related to libffcall.
> 
> No, libffcall was triggering execheap. ...
> I've not yet seen any execstack complaints.

Oh, this is more complex than I thought.

> So as far as I know so far, current clisp has no issues with selinux
> on latest fedora.

Yup. I keep this issue on my radar, but won't do something about it
unless someone reports a real problem.

Bruno