[grsec] Reboot problem - resolved but leaves a question

[John Logsdon]

The problem of not being able to login - either at the console or via ssh
or not being able to spawn an xterm off an xterm has been solved but it
leaves a question that readers of this list may be able to suggest an
answer.

You may recall that after having recompiled grsec 2.4.28 I couldn't log
in.  I did doubt it had anything to do with grsec but that was the last
thing that I did.  There was no evidence of any breakin and eventually the
penny dropped that it could be a shell thing.  My sysadmin replaced the
bash2 shell with a csh and login was achieved.  After that we reinstalled
bash --force and all has been well.

The puzzle was that bash passed all MD5 tests - there was no evidence of
it having been perverted and the issue remained a puzzle.

A possible solution came to light today from someone on a list that I
suscribe to who had had the same problem a few weeks back for some users -
there aren't that many users on my system at the moment.  It turned out to
be a SELinux issue - the extra permissions of SEL had reared their heads.
These are of course built into the directory structure for SEL, totally
unlike the grsec philosophy of doing everything in the kernel so leaving
all the libraries and architecture unchanged.

Now I am using Fedora Core 2 and everything is compiled with SEL, although
I have it disabled.  It is essentially impossible to decouple them.  It
could therefore be that for some reason it wasn't the binary that got
corrupted but the directory entry and the role or whatever wasn't set.  
There were no error or warning messages anywhere - no avc messages.

Is this even theoretically possible?  Has anyone heard of it before? Could
list members suggest an alternative to FC2 to use that is not too
difficult to migrate to - ie it has the same structure?  

I don't want this sort of thing to happen in production and unfortunately
both FC2 and SEL folk are not too helpful when it could be their baby
that's rocked the cradle.

TIA

John

John Logsdon                               "Try to make things as simple
Quantex Research Ltd, Manchester UK         as possible but not simpler"
j.logsdon at quantex-research.com              a.einstein at relativity.org
+44(0)161 445 4951/G:+44(0)7717758675       www.quantex-research.com


On Mon, 13 Dec 2004, John Logsdon wrote:

> I have a reboot problem.  
> 
> The only thing that makes me wonder if it's anything to do with grsec is
> that I altered the PaX configuration - basically switched it on and unset
> the grsec sysctl facility.  The grsec config is essentially that shown on
> the Gentoo grsec2 page except with:
> 
> CONFIG_GRKERNSEC_PROC_USER=y
> CONFIG_GRKERNSEC_USERGROUP is not set
> 
> CONFIG_GRKERNSEC_EXECLOG=n
> CONFIG_GRKERNSEC_CHROOT_EXECLOG=n
> CONFIG_GRKERNSEC_AUDIT_TEXTREL=n
> 
> CONFIG_GRKERNSEC_TPE_GID=20
> 
> and gid=20 is group paxtpe but with no members.
> 
> After compiling the new kernel, going through to make install, I found
> that I cant ssh in *even before rebooting*.  
> 
> And if I reboot, I still can't ssh in to any user.
> 
> Is there anything in make install that could have altered a running kernel
> or facility?
> 
> TIA
> 
> John
> 
> John Logsdon                               "Try to make things as simple
> Quantex Research Ltd, Manchester UK         as possible but not simpler"
> j.logsdon at quantex-research.com              a.einstein at relativity.org
> +44(0)161 445 4951/G:+44(0)7717758675       www.quantex-research.com
> 
> 
> _______________________________________________
> grsecurity mailing list
> grsecurity at grsecurity.net
> http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
>