* [kernel-hardening] -ow features @ 2011-07-23 16:27 Solar Designer 2011-07-29 9:00 ` Vasiliy Kulikov 0 siblings, 1 reply; 7+ messages in thread From: Solar Designer @ 2011-07-23 16:27 UTC (permalink / raw) To: kernel-hardening Vasiliy, Can you please post a summary on the status of -ow patch features as it relates to mainline acceptance of their equivalents? Specifically, what's the status on symlink, hard link, and FIFO restrictions? Did Kees submit some(?) of those and they got rejected? And you're not getting into this because of that rejection? This is something I'd really like to get in, so perhaps another attempt is in order. Thanks, Alexander ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [kernel-hardening] -ow features 2011-07-23 16:27 [kernel-hardening] -ow features Solar Designer @ 2011-07-29 9:00 ` Vasiliy Kulikov 2011-07-29 17:30 ` Solar Designer 0 siblings, 1 reply; 7+ messages in thread From: Vasiliy Kulikov @ 2011-07-29 9:00 UTC (permalink / raw) To: kernel-hardening Solar, On Sat, Jul 23, 2011 at 20:27 +0400, Solar Designer wrote: > Can you please post a summary on the status of -ow patch features as it > relates to mainline acceptance of their equivalents? Sorry for the delay, I didn't somehow noticed this email. HARDEN_STACK* The code similar to -ow patch is ready, but it doesn't handle DSO cases of stack usage. I've described the problem here: http://www.openwall.com/lists/kernel-hardening/2011/07/18/8 HARDEN_VM86 The code similar to -ow patch is ready, but I don't know how it should be implemented relative to LSM/seccomp/etc. It looks like a small feature, which is not consistent with current upstream security architecture. I've described the problem here: http://www.openwall.com/lists/kernel-hardening/2011/06/19/2 Without the major change of the configuration mechanism it's impossible to get it applied. HARDEN_PAGE0 It is a part of Linux for many years. Distros may setup their own mmap_min_addr limit and the default is 64K. So, I don't see what can be improved here. HARDEN_LINK HARDEN_FIFO These are implemented in YAMA LSM. Kees Cook's last attempt (AFAIK) is: http://marc.info/?l=linux-security-module&m=130023775422255&w=2 James Morris' reaction: http://marc.info/?l=linux-security-module&m=130032319219333&w=2 So, the issue is that LSM guys say that LSM is the place where only enhanced access control schemes may be located, but VFS folks say that all similar non-POSIX restrictions should go into LSM as a configurable security feature (extern relative to VFS). This inconsistency is really nasty :( HARDEN_PROC The patch as in -ow received negative response from Andrew Morton as too limited: http://www.openwall.com/lists/kernel-hardening/2011/06/21/3 I'm working on it. The demonstration is: http://www.openwall.com/lists/kernel-hardening/2011/07/26/5 HARDEN_NLIMIT_NPROC The discussion: http://www.openwall.com/lists/kernel-hardening/2011/06/12/9 The latest patch: http://www.openwall.com/lists/kernel-hardening/2011/07/29/3 (It has already got a Reviewed-by from James, which is very good.) HARDEN_SHM The patch: http://www.openwall.com/lists/kernel-hardening/2011/06/22/4 It was applied first to -mm tree, now it is merged into Linus' linux-2.6 tree (it will be part of Linux 3.1). Special handling of fd 0,1,2 (Linux 2.0/2.2) for set*id It is handled in glibc now by opening /dev/{null,full}, however, I see (minor) drawbacks: 1) It's possible to have a chroot without polluted /dev/, so setuid inside of chroot might fail to reopen fds. 2) It's not handled in other libc implementations. Other than that, it already works. Privileged IP aliases (Linux 2.0) I think it was fully obsoleted with network namespaces. Thanks, -- Vasiliy ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [kernel-hardening] -ow features 2011-07-29 9:00 ` Vasiliy Kulikov @ 2011-07-29 17:30 ` Solar Designer 2011-07-29 18:00 ` Vasiliy Kulikov 2011-07-29 18:06 ` Vasiliy Kulikov 0 siblings, 2 replies; 7+ messages in thread From: Solar Designer @ 2011-07-29 17:30 UTC (permalink / raw) To: kernel-hardening Vasiliy, On Fri, Jul 29, 2011 at 01:00:53PM +0400, Vasiliy Kulikov wrote: > HARDEN_STACK* > > The code similar to -ow patch is ready, but it doesn't handle DSO cases > of stack usage. I've described the problem here: > > http://www.openwall.com/lists/kernel-hardening/2011/07/18/8 Right. > HARDEN_VM86 > > The code similar to -ow patch is ready, but I don't know how it should > be implemented relative to LSM/seccomp/etc. It looks like a small > feature, which is not consistent with current upstream security > architecture. I've described the problem here: > > http://www.openwall.com/lists/kernel-hardening/2011/06/19/2 > > Without the major change of the configuration mechanism it's impossible > to get it applied. In -ow, there's also CONFIG_BINFMT_ELF_AOUT. When it is not enabled - and by default it is not - uselib(2) is disabled (returns -ENOSYS) and parts of binfmt_elf.c responsible for loading a.out libraries for ELF binaries are also disabled (truly ancient stuff). We need something like this for 3.x and RHEL6 kernels too. Maybe the CONFIG_BINFMT_ELF_AOUT option may be accepted upstream on the grounds that it's similar to other CONFIG_BINFMT_* options? > HARDEN_PAGE0 > > It is a part of Linux for many years. Distros may setup their own > mmap_min_addr limit and the default is 64K. So, I don't see what can be > improved here. Sure. Historically, I introduced it into 2.4.x-ow before there was mmap_min_addr, then when mainline went with mmap_min_addr and it got into upstream 2.4.x kernels, I dropped my code and made the HARDEN_PAGE0 option merely change the default for mmap_min_addr (it was 0 in 2.4.x by default, IIRC). Now that the default has also changed upstream, there's no need for this option anymore. > HARDEN_LINK > HARDEN_FIFO > > These are implemented in YAMA LSM. Kees Cook's last attempt (AFAIK) is: > > http://marc.info/?l=linux-security-module&m=130023775422255&w=2 > > James Morris' reaction: > > http://marc.info/?l=linux-security-module&m=130032319219333&w=2 > > So, the issue is that LSM guys say that LSM is the place where only > enhanced access control schemes may be located, but VFS folks > say that all similar non-POSIX restrictions should go into LSM as a > configurable security feature (extern relative to VFS). This > inconsistency is really nasty :( So do you intend to skip HARDEN_LINK and HARDEN_FIFO, and work on them for RHEL6/OpenVZ kernels for Owl only (well, maybe also for OpenVZ and Red Hat if they choose accept this into their trees)? > HARDEN_PROC > > The patch as in -ow received negative response from Andrew Morton as too > limited: > > http://www.openwall.com/lists/kernel-hardening/2011/06/21/3 > > I'm working on it. The demonstration is: > > http://www.openwall.com/lists/kernel-hardening/2011/07/26/5 OK. > HARDEN_NLIMIT_NPROC > > The discussion: > > http://www.openwall.com/lists/kernel-hardening/2011/06/12/9 > > The latest patch: > > http://www.openwall.com/lists/kernel-hardening/2011/07/29/3 > > (It has already got a Reviewed-by from James, which is very good.) Great. I just recalled that in -ow I also patched the added RLIMIT_NPROC check into copies of the execve() code in 32-bit syscall wrappers on 64-bit systems - e.g., do_execve32() in arch/mips64/kernel/linux32.c. To give credit where it's due, per my notes it was Brad Spengler who noticed that these had been overlooked and informed me in 2003 or so. Is this still relevant to current kernels? > HARDEN_SHM > > The patch: > > http://www.openwall.com/lists/kernel-hardening/2011/06/22/4 > > It was applied first to -mm tree, now it is merged into Linus' linux-2.6 > tree (it will be part of Linux 3.1). Great. > Special handling of fd 0,1,2 (Linux 2.0/2.2) for set*id > > It is handled in glibc now by opening /dev/{null,full}, however, I see > (minor) drawbacks: > > 1) It's possible to have a chroot without polluted /dev/, so setuid > inside of chroot might fail to reopen fds. > > 2) It's not handled in other libc implementations. > > Other than that, it already works. Right. Is the glibc implementation fail-close or fail-open - that is, what happens if e.g. /dev/{null,full} don't exist? Does the program continue to start up, but without this safety measure? Either way, I think we should propose this for the kernel - post an RFC. > Privileged IP aliases (Linux 2.0) > > I think it was fully obsoleted with network namespaces. Yes, this is not needed anymore (for different reasons, though). Thanks, Alexander ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [kernel-hardening] -ow features 2011-07-29 17:30 ` Solar Designer @ 2011-07-29 18:00 ` Vasiliy Kulikov 2011-07-29 18:06 ` Vasiliy Kulikov 1 sibling, 0 replies; 7+ messages in thread From: Vasiliy Kulikov @ 2011-07-29 18:00 UTC (permalink / raw) To: kernel-hardening On Fri, Jul 29, 2011 at 21:30 +0400, Solar Designer wrote: > > HARDEN_LINK > > HARDEN_FIFO > > > > These are implemented in YAMA LSM. Kees Cook's last attempt (AFAIK) is: > > > > http://marc.info/?l=linux-security-module&m=130023775422255&w=2 > > > > James Morris' reaction: > > > > http://marc.info/?l=linux-security-module&m=130032319219333&w=2 > > > > So, the issue is that LSM guys say that LSM is the place where only > > enhanced access control schemes may be located, but VFS folks > > say that all similar non-POSIX restrictions should go into LSM as a > > configurable security feature (extern relative to VFS). This > > inconsistency is really nasty :( > > So do you intend to skip HARDEN_LINK and HARDEN_FIFO, and work on them > for RHEL6/OpenVZ kernels for Owl only (well, maybe also for OpenVZ and > Red Hat if they choose accept this into their trees)? Yes, I don't see how can I improve the situation with upstream. Kees Cook tried to push it several times, providing various good arguments. > I just recalled that in -ow I also patched the added RLIMIT_NPROC check > into copies of the execve() code in 32-bit syscall wrappers on 64-bit > systems - e.g., do_execve32() in arch/mips64/kernel/linux32.c. To give > credit where it's due, per my notes it was Brad Spengler who noticed > that these had been overlooked and informed me in 2003 or so. Is this > still relevant to current kernels? No, grep shows no usage in arch/. > > Special handling of fd 0,1,2 (Linux 2.0/2.2) for set*id > > > > It is handled in glibc now by opening /dev/{null,full}, however, I see > > (minor) drawbacks: > > > > 1) It's possible to have a chroot without polluted /dev/, so setuid > > inside of chroot might fail to reopen fds. > > > > 2) It's not handled in other libc implementations. > > > > Other than that, it already works. > > Right. Is the glibc implementation fail-close or fail-open - that is, > what happens if e.g. /dev/{null,full} don't exist? Does the program > continue to start up, but without this safety measure? No, it crashes (tries to execute "hlt" in a loop). > Either way, I think we should propose this for the kernel - post an RFC. OK. However, I think it will be rejected with a reason "it is a doubtful feature, which breaks POSIX and it is already implemented in a userspace libc". Thanks, -- Vasiliy ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [kernel-hardening] -ow features 2011-07-29 17:30 ` Solar Designer 2011-07-29 18:00 ` Vasiliy Kulikov @ 2011-07-29 18:06 ` Vasiliy Kulikov 2011-07-29 22:42 ` Solar Designer 1 sibling, 1 reply; 7+ messages in thread From: Vasiliy Kulikov @ 2011-07-29 18:06 UTC (permalink / raw) To: kernel-hardening Solar, On Fri, Jul 29, 2011 at 21:30 +0400, Solar Designer wrote: > > HARDEN_VM86 > > > > The code similar to -ow patch is ready, but I don't know how it should > > be implemented relative to LSM/seccomp/etc. It looks like a small > > feature, which is not consistent with current upstream security > > architecture. I've described the problem here: > > > > http://www.openwall.com/lists/kernel-hardening/2011/06/19/2 > > > > Without the major change of the configuration mechanism it's impossible > > to get it applied. > > In -ow, there's also CONFIG_BINFMT_ELF_AOUT. When it is not enabled - > and by default it is not - uselib(2) is disabled (returns -ENOSYS) and > parts of binfmt_elf.c responsible for loading a.out libraries for ELF > binaries are also disabled (truly ancient stuff). We need something > like this for 3.x and RHEL6 kernels too. > > Maybe the CONFIG_BINFMT_ELF_AOUT option may be accepted upstream on the > grounds that it's similar to other CONFIG_BINFMT_* options? Do you propose to move all ELF_AOUT code to a configurable option, just like STRICT_DEVMEM? Looks like a good plan - kernel developers don't like to support legacy stuff. If it is moved to a config option, then in some years it could be even fully removed (if I understand the AOUT significance). -- Vasiliy ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [kernel-hardening] -ow features 2011-07-29 18:06 ` Vasiliy Kulikov @ 2011-07-29 22:42 ` Solar Designer 2011-07-30 18:20 ` [kernel-hardening] BINFMT_ELF_AOUT (was: -ow features) Vasiliy Kulikov 0 siblings, 1 reply; 7+ messages in thread From: Solar Designer @ 2011-07-29 22:42 UTC (permalink / raw) To: kernel-hardening Vasiliy, On Fri, Jul 29, 2011 at 10:06:14PM +0400, Vasiliy Kulikov wrote: > On Fri, Jul 29, 2011 at 21:30 +0400, Solar Designer wrote: > > In -ow, there's also CONFIG_BINFMT_ELF_AOUT. When it is not enabled - > > and by default it is not - uselib(2) is disabled (returns -ENOSYS) and > > parts of binfmt_elf.c responsible for loading a.out libraries for ELF > > binaries are also disabled (truly ancient stuff). We need something > > like this for 3.x and RHEL6 kernels too. > > > > Maybe the CONFIG_BINFMT_ELF_AOUT option may be accepted upstream on the > > grounds that it's similar to other CONFIG_BINFMT_* options? > > Do you propose to move all ELF_AOUT code to a configurable option, just Yes. > like STRICT_DEVMEM? I'm not sure why you mention this one as an example. I think the CONFIG_BINFMT_ELF_AOUT name may be used, and this option will thus look (and work) similar to other CONFIG_BINFMT_* options. > Looks like a good plan - kernel developers don't > like to support legacy stuff. If it is moved to a config option, then > in some years it could be even fully removed (if I understand the AOUT > significance). Right. This stuff has been obsolete for 15+ years, at least for native Linux binaries. Alexander ^ permalink raw reply [flat|nested] 7+ messages in thread
* [kernel-hardening] BINFMT_ELF_AOUT (was: -ow features) 2011-07-29 22:42 ` Solar Designer @ 2011-07-30 18:20 ` Vasiliy Kulikov 0 siblings, 0 replies; 7+ messages in thread From: Vasiliy Kulikov @ 2011-07-30 18:20 UTC (permalink / raw) To: kernel-hardening Solar, On Sat, Jul 30, 2011 at 02:42 +0400, Solar Designer wrote: > > like STRICT_DEVMEM? > > I'm not sure why you mention this one as an example. Because it guards some doubtful feature, which is considered harmful for the generic system. > I think the > CONFIG_BINFMT_ELF_AOUT name may be used, and this option will thus look > (and work) similar to other CONFIG_BINFMT_* options. > > > Looks like a good plan - kernel developers don't > > like to support legacy stuff. If it is moved to a config option, then > > in some years it could be even fully removed (if I understand the AOUT > > significance). > > Right. This stuff has been obsolete for 15+ years, at least for native > Linux binaries. Looks like it was almost fully removed in 2.6.25: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d20894a23708c2af75966534f8e4dedb46d48db2 The only untouched part is load_elf_library(). I think I can simply remove it in the proposed patch as full a.out removal from ELF format was scheduled in 2.6.25. Thanks, -- Vasiliy ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-07-30 18:20 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-07-23 16:27 [kernel-hardening] -ow features Solar Designer 2011-07-29 9:00 ` Vasiliy Kulikov 2011-07-29 17:30 ` Solar Designer 2011-07-29 18:00 ` Vasiliy Kulikov 2011-07-29 18:06 ` Vasiliy Kulikov 2011-07-29 22:42 ` Solar Designer 2011-07-30 18:20 ` [kernel-hardening] BINFMT_ELF_AOUT (was: -ow features) Vasiliy Kulikov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.