Bug#330592: init segfault when /selinux exists but a policy can't be loaded
tags 330592 -unreproducible +etch -help severity 330592 critical found 330592 2.86.ds1-20 thanks The reason for the critical level is that this bug has the potential to render the entire system unbootable unless glibc catches the invalid free() calls. See description below for further details. James Westby wrote: However it did not cause a segfault, and I got a completed boot. I did however get *** glibc detected *** free(): invalid pointer: 0x0804feb5 *** *** glibc detected *** free(): invalid pointer: 0x0804feb5 *** so maybe this is what was the segfault before. I think I've nailed it. in src/init.c:150, after selinuxfs has been sucessfully mounted (but only if it has been succesfully mounted, which would explain why the problem appeared after the /selinux dir was created), is the following step: selinux_mnt = SELINUXMNT; /* set manually since we mounted it */ (and SELINUXMNT is already defined as /selinux/) However, with changes made to libselinux1 since the selinux patch was written for sysvinit, selinux_mnt is now a variable internal to the selinux1 library. In src/init.c:70 of libselinux1 (1.32), we have this line: free(selinux_mnt); So when the children fork:ed by init exit (in the spawn() function from src/init.c), the exit function of the libselinux1 library will also be called and try to free selinux_mnt which has not been allocated with malloc. The result is of course that the child blows up or, due to unrelated changes in glibc, survives with a warning. If it blows up, the error handlers will ensure that it continues respawning over and over. So, the fix would be to apply the selinux patch to sysvinit that is already included in more recent versions (which use the selinux_init_load_policy function instead of manipulating selinux_mnt). Thus I'll close the bug as fixed in sysvinit 2.86.ds1-34. I still suspect that #344471 is a dupe of this bug, but I'll leave that up to the maintainers to deal with. -- David Härdeman
Bug#330592: init segfault when /selinux exists but a policy can't be loaded
On Wed, November 1, 2006 23:08, James Westby said: It seems clear that the actions I described do not trigger a segfault like the original report, however it is not clear to me that these actions are the ones from the original report. Ernest has stated that he did not have a policy installed, which I find very odd, as I believe SELinux will not try and load a policy if one has not been installed. From reading the source (of version -20), init will try to load a policy provided that: 1) /selinux is available; and 2) selinuxfs can be successfully mounted on /selinux The kernel command line options doesn't seem to matter for whether the policies are loaded or not. Thinking about it now it is conceivable that the bug was fixed by a change in a different package, either: * The kernel no longer tries to initialise SELinux by default (I doubt it ever did though). * SELinux used to try and load a policy even if one has not been configured/installed. * One of the libraries that init depends on had a bug which has been fixed -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330592:
tags 330592 +unreproducible thanks James Westby wrote: So I managed to get the above message (for policy version 20) by # rm -rf /etc/selinux However it did not cause a segfault, and I got a completed boot. I did however get *** glibc detected *** free(): invalid pointer: 0x0804feb5 *** *** glibc detected *** free(): invalid pointer: 0x0804feb5 *** so maybe this is what was the segfault before. I've also tried to reproduce this. I did a fresh install of testing in a qemu VM, and then followed the steps listed by James (install some SELinux package, make sure /selinux is created, boot with selinux=1 a couple of times, mv /etc/selinux /etc/selinux.gone, reboot). I also saw the glibc detected and Can't open... messages but no crash. In order to make sure that the invalid free() calls (which, looking at the addresses seem to try to free variables which are on the stack) I sprinkled print (initlog) statements in different places of src/init.c, and after a couple of iterations I found that init is sleeping inside a select() call when the glibc messages are printed (they are printed sometime during the rcS stage of the boot by the way). Just to make sure I also added debugging output prior to each free() call made by init (which revealed nothing out of the ordinary). So I'm fairly certain that the glibc messages have nothing to do with init and it seems that this bug has been fixed (somehow). I'd still like to trace down what *is* causing the glibc warnings though, just to be sure. I'll try to fiddle with the rcS scripts next to see if I can find the offender. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330592: init segfault when /selinux exists but a policy can't be loaded
On (01/11/06 13:53), David Härdeman wrote: tags 330592 +unreproducible thanks James Westby wrote: So I managed to get the above message (for policy version 20) by # rm -rf /etc/selinux However it did not cause a segfault, and I got a completed boot. I did however get *** glibc detected *** free(): invalid pointer: 0x0804feb5 *** *** glibc detected *** free(): invalid pointer: 0x0804feb5 *** so maybe this is what was the segfault before. I've also tried to reproduce this. I did a fresh install of testing in a qemu VM, and then followed the steps listed by James (install some SELinux package, make sure /selinux is created, boot with selinux=1 a couple of times, mv /etc/selinux /etc/selinux.gone, reboot). Hi, It seems clear that the actions I described do not trigger a segfault like the original report, however it is not clear to me that these actions are the ones from the original report. Ernest has stated that he did not have a policy installed, which I find very odd, as I believe SELinux will not try and load a policy if one has not been installed. Ernest, can you confirm that you have *never* had an SELinux policy installed? Have you ever changed any SELinux related settings? Does your kernel command line include selinux=1 (or your kernel have the equivalent .config setting?). Thinking about it now it is conceivable that the bug was fixed by a change in a different package, either: * The kernel no longer tries to initialise SELinux by default (I doubt it ever did though). * SELinux used to try and load a policy even if one has not been configured/installed. It might be worth investigating this, and I might find time to do so at some point. What I think is important is that it seems like you now have to do something bad to your system to get to the state that it cannot load a policy, unless there is another way to trigger this that I have overlooked. James -- James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330592: sysvinit: init panic after creating directory /selinux/
Hi,
I have managed to get some more information on this bug. I have included
my findings below, but the short story is that I think it might be
somewhat fixed.
Can you still reproduce this bug? If so it would be interesting to get a
bit more information, for instance a full log of the crashing startup.
It would also be good to have some information about your system when it
is running normally. For instance all the information in /selinux and
/etc/selinux/.
A few days ago, during boot, just before init startup, I too noticed the
same message which claimed directory /selinux/ was not found.
thinking selinux was badly installed I created that directory... and
forgot about it. Tonight, because of a change in my system, I rebooted,
to have Init scream this message to me :
INIT: PANIC: segmentation violation! sleeping for 30 seconds. INIT:
PANIC: segmentation violation! sleeping for 30 seconds. etc ...
Obviously it took me while to link the 2 events together: I thought my
disk was corrupt, except the lockup was always happenning at the same
place, and also I noticed that the message which claimed /selinux/ was
missing, had changed to:
Can't open '/etc/security/selinux/policy.19': no such file or directory.
This is the interesting part. I believe this is where Fedora keeps their
configuration, on Debian it is
/etc/selinux/policy-name/policy.version
However the above location is considered the compat location by
libselinux. The relevant bit of code is in
libselinux1-1.30.28/src/selinux_config.c:169
if (access(SELINUXDIR, F_OK) != 0) {
selinux_policyroot = SECURITYDIR;
selinux_rootpath = SECURITYDIR;
use_compat_file_path = 1;
return;
}
where SECURITYDIR is /etc/security/
so insysvinit-2.86.ds1/src/init.c:189 (after ./debian/rules patch-stamp)
snprintf(policy_file,sizeof(policy_file),%s.%d,selinux_binary_policy_path(),policy_version);
fd = open(policy_file, O_RDONLY);
if (fd 0) {
/* Check previous version to see if old policy is available
*/
snprintf(policy_file,sizeof(policy_file),%s.%d,selinux_binary_policy_path(),policy_version-1);
fd = open(policy_file, O_RDONLY);
if (fd 0) {
printf( Can't open '%s.%d': %s\n,
selinux_binary_policy_path(),policy_version,strerror(errno));
goto UMOUNT;
}
}
which you can see creates the above message.
So I managed to get the above message (for policy version 20) by
# rm -rf /etc/selinux
However it did not cause a segfault, and I got a completed boot. I did
however get
*** glibc detected *** free(): invalid pointer: 0x0804feb5 ***
*** glibc detected *** free(): invalid pointer: 0x0804feb5 ***
so maybe this is what was the segfault before.
I have looked for relevant code changes in bith sysvinit and libselinux
since your report and I can't see anything that seems like it would have
fixed it. However I can't see anything that would cause a segfault
either.
Once I removed the offending directory, and rebooted, I noticed the
normal :
INIT : Entering run level 2
where juste before init panicked.
This is due to the fact that if /selinux can't be mounted it bails out a
lot earlier.
So, the 'solution' was easy, but the reason this might be a more serious
bug is because normal users would not be able to restart from a system
without a functioning init.
Final note : this crash might happen because I have a custom kernel. I
did include selinux in the build, though.
I used fresh etch install in a qemu VM, with stock .17 kernel. I
installed selinux-basics and selinux-policy-refpolicy-targeted, did a
couple of reboots, and then did rf -rf /etc/selinux/, and rebooted with
selinux=1 on the kernel command line. I am using
libselinux1 1.30.28-2
sysvinit 2.86.ds1-20
libc6 2.3.6.ds1-4
libsepol1 1.12.26-2
So, as I said above it seems this bug might have been fixed along the
way, but I'm not totally convinced that I have matched your setup. It
also seems as if it requires a very broken setup to trigger it
(/etc/selinux/ unreadable).
I have also just noticed that you are on a different arch, so here is a
list of possible candidates for why I cannot reproduce,
amd64 vs i386
Kernel 2.6.13 vs 2.6.17
version of libselinux1
version of sysvinit
different setup
Any information you could provide would be useful,
Thanks,
James
--
James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/
seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330592: sysvinit: init panic after creating directory /selinux/
Hi, On Sunday 22 October 2006 16:11, you wrote: Can you still reproduce this bug? If so it would be interesting to get a bit more information, for instance a full log of the crashing startup. No, I cannot. I checked, but could not find, if a /selinux/ not found error was still given during boot. So message is gone. I don't know when that happened, nor do I know if that happen because of a kernel upgrade, or a debian update. But then, my system has been updated many times since that bug report. I added the directory /selinux/ and rebooted, but system did not care. I removed directory again. It would also be good to have some information about your system when it is running normally. For instance all the information in /selinux and /etc/selinux/. Well, since your asking, I don't have any selinux policy installed currently, nor did I have it then (when I did the bug report). The only thing I do have and had then as wel was libselinux1 and libsepol1, as they are in the required category. Any information you could provide would be useful, Would it help if I did install a policy, and send you an install report ? Cheers, Ernest. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330592: sysvinit: init panic after creating directory /selinux/
Package: sysvinit Version: 2.86.ds1-3 Severity: normal this bug is related to minor bugs : #328474 #329328 but might be more serious. A few days ago, during boot, just before init startup, I too noticed the same message which claimed directory /selinux/ was not found. thinking selinux was badly installed I created that directory... and forgot about it. Tonight, because of a change in my system, I rebooted, to have Init scream this message to me : INIT: PANIC: segmentation violation! sleeping for 30 seconds. INIT: PANIC: segmentation violation! sleeping for 30 seconds. etc ... Obviously it took me while to link the 2 events together: I thought my disk was corrupt, except the lockup was always happenning at the same place, and also I noticed that the message which claimed /selinux/ was missing, had changed to: Can't open '/etc/security/selinux/policy.19': no such file or directory. Once I removed the offending directory, and rebooted, I noticed the normal : INIT : Entering run level 2 where juste before init panicked. So, the 'solution' was easy, but the reason this might be a more serious bug is because normal users would not be able to restart from a system without a functioning init. Final note : this crash might happen because I have a custom kernel. I did include selinux in the build, though. Groetjes, Ernest ter Kuile. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages sysvinit depends on: ii coreutils 5.2.1-2.1 The GNU core utilities ii initscripts 2.86.ds1-2 Standard scripts needed for bootin ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libselinux1 1.26-1 SELinux shared libraries ii libsepol1 1.8-1 Security Enhanced Linux policy lib ii sysv-rc 2.86.ds1-3 Standard boot mechanism using syml sysvinit recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
