-ow features
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
Solar,
Quoted 2 lines · Solar Designer
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_LINKHARDEN_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,
Signature · 1 line
Vasiliy
Vasiliy,
Quoted 6 lines · Vasiliy Kulikov
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:
Right.
Quoted 11 lines
HARDEN_VM86The 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?
Quoted 5 lines
HARDEN_PAGE0It is a part of Linux for many years. Distros may setup their own
mmap_min_addrlimit 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.
Quoted 9 lines
HARDEN_LINKHARDEN_FIFOThese 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:
Quoted 7 lines
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)?
Quoted 10 lines
HARDEN_PROCThe 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:
OK.
Quoted 11 lines
HARDEN_NLIMIT_NPROCThe 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?
Quoted 8 lines
HARDEN_SHMThe 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.
Quoted 11 lines
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.
Quoted 3 lines
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
Quoted 17 lines · Solar Designer
Quoted 9 lines
HARDEN_LINKHARDEN_FIFOThese 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:
Quoted 7 lines
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 :(
Quoted 3 lines
So do you intend to skip
HARDEN_LINKandHARDEN_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.
Quoted 6 lines
I just recalled that in -ow I also patched the added
RLIMIT_NPROCcheck into copies of theexecve()code in 32-bit syscall wrappers on 64-bit systems - e.g.,do_execve32()inarch/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/.
Quoted 8 lines
Quoted 8 lines
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.
Quoted 7 lines
Quoted 3 lines
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).
Quoted 1 line
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,
Signature · 1 line
Vasiliy
Solar,
Quoted 12 lines · Solar Designer
Quoted 11 lines
HARDEN_VM86The 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.
Quoted 8 lines
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 ofbinfmt_elf.cresponsible 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_AOUToption 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).
Signature · 1 line
Vasiliy
Vasiliy,
Quoted 11 lines · Vasiliy Kulikov
Quoted 8 lines · Solar Designer
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 ofbinfmt_elf.cresponsible 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_AOUToption may be accepted upstream on the grounds that it's similar to other CONFIG_BINFMT_* options?Do you propose to move all
ELF_AOUTcode to a configurable option, just
Yes.
Quoted 1 line
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.
Quoted 4 lines
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
[kernel-hardening] BINFMT_ELF_AOUT (was: -ow features)
Solar,
Quoted 3 lines · Solar Designer
Quoted 1 line
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.
Quoted 11 lines
I think the
CONFIG_BINFMT_ELF_AOUTname may be used, and this option will thus look (and work) similar to other CONFIG_BINFMT_* options.Quoted 4 lines
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:
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,
Signature · 1 line
Vasiliy