Bug 151145
| Summary: | segfaults when changing context | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Enrico Scholz <rh-bugzilla> |
| Component: | vixie-cron | Assignee: | Marcela Mašláňová <mmaslano> |
| Status: | CLOSED NOTABUG | QA Contact: | Brock Organ <borgan> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-01-08 15:42:00 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 163883 | ||
This is now fixed with vixie-cron-4.1-26_FC4 . A workaround for this bug would be to copy the /etc/security/default_contexts or the /usr/home/$user/.default_contexts into the chroot environment . Please note that any increase in security obtained through use of a chroot environment is more than offset by disabling SELinux, and that by using SELinux properly, a far more secure environment could be achieved than that obtained by use of a chroot . Also note that if you wish to disable certain users from using cron, a much better way of doing so would be to use PAM access.conf or limits.conf . However, crond should not segfault if the context for a user cannot be found. This is now fixed, and will be in Rawhide / FC4t2 shortly. yes, I found this workaround also. My chroot is secure as I am using Linux-Vserver (http://linux-vserver.org) technology for it. PAM access.conf is a little bit problematic as it requires a login-TTY which is not set by the most servers. So using is generally in system-auth is not possible. Adding it manually to pam.d/crond would be possible but may cause problems on program updates. Linux-Vserver is still way less secure than SELinux when properly configured. Also adding the line 'account required /lib/security/$ISA/pam_access.so' to /etc/pam.d/crond will remain across updates because it is installed as a %config file - crond uses the 'crond' PAM_TTY "login-TTY", which has no more significance to PAM than the name - it is not a real "terminal" . > Linux-Vserver is still way less secure than SELinux I am not aware of any attack against Linux-Vserver which would not work against SELinux also. But SELinux has the following, additional problems: * it has a strange kernel-API; relying on the /proc + /selinux filesystem makes it unsuitable for any chroot tasks * the missing chroot functionality does not allow virtualization * it is very difficultly to configure. The default setup does not fit for more advanced tasks so you have to configure it yourself. When doing this, the upgrade path with 'fixfiles -C ...' does not work and you are just busy with rebooting and relabeling the entire filesystem. > when properly configured. yes, this is a problem with SELinux. It is very difficultly to configure while VServer uses the well-known Unix configuration style. So, most SELinux machines will not be "properly configured" and less secure than corresponding vservers. Well, are you content with vixie-cron-4.1-26_FC4? I know there are still some problems with SElinux. If you have some problems with configuration and I have to fix something in cron, let me know. |
Description of problem: crond dies when executing jobs: | Program received signal SIGSEGV, Segmentation fault. | 0x97fddfba in *setexeccon_internal (context=0x11d3cc <Address 0x11d3cc out of bounds>) | at setexeccon.c:15 | 15 ret = write(fd, context, strlen(context)+1); | (gdb) bt | #0 0x97fddfba in *setexeccon_internal (context=0x11d3cc <Address 0x11d3cc out of bounds>) | at setexeccon.c:15 | #1 0x6aab1988 in do_command (e=0x6aab86f0, u=0x6aab8698) at do_command.c:334 | #2 0x6aab11fc in job_runqueue () at job.c:66 | #3 0x6aaaed3e in main (argc=1, argv=0x4236e629) at cron.c:256 Previous breakpoints were | Breakpoint 2, do_command (e=0x6aab86f0, u=0x6aab8698) at do_command.c:71 | 71 Debug(DPROC, ("[%ld] do_command(%s, (%s,%ld,%ld))\n", | (gdb) p u | $1 = (user *) 0x6aab8698 | (gdb) p *u | $2 = {next = 0x0, prev = 0x6aab8190, name = 0x6aab81c0 "*system*", mtime = 1109646298, | crontab = 0x6aab9700, scontext = 0x11d3cc <Address 0x11d3cc out of bounds>} | (gdb) c | Continuing. | Attaching after fork to child process 28298. | Attaching after fork to child process 28299. | [Switching to process 28299] | | Breakpoint 1, 0x97fddf7e in *setexeccon_internal (context=0x11d3cc <Address 0x11d3cc out of bounds>) | at setexeccon.c:7 | 7 { | (gdb) c As you see, 'u->scontext' is uninitialized which is caused in get_security_context() (user.c) by | if (get_default_context(name, NULL, &scontext)) { | if (security_getenforce() > 0) { | log_it(name, getpid(), "No SELinux security context",tabname); | return -1; | } else { | log_it(name, getpid(), "No security context but SELinux in permissive mode, co | } | } On my system (a chroot environment), get_default_context() fails and 'scontext' gets never be initialized. Version-Release number of selected component (if applicable): vixie-cron-4.1-24_FC4 libselinux-1.22-1