On Thu, 10 May 2001, Chris Wright wrote: > > > > 2) I see, currently, that syscalls are not hooked in a generic manner. > > >From exceptionally brief scanning of the archives, this seems to be a > > debated point. > > Are there plans to hook syscalls? If not, I can make a very strong > > argument to do so. Let me know if you want to hear it. > > Some syscalls are hooked right now. In general we have not hooked every > syscall. I value your input here. All right, here goes :-) I'm going to propose an argument which detaills why some form of hooking or control on a per-syscall level is required. As a quick disclaimer, I'm not necessarily saying that LSM needs to provide this. I'm just arguing that _something_ should provide it. We're embedded firmly in practical security now, and the principle that I like to apply is to minimize the amount of privileged code paths available to attackers. Applying this principle can give very strong security. I'll use my vsftpd as an example. The vast majority of the code is carefully run as a non-root user in a chroot() environment. The chroot() is particularly powerful, because you can choose a filesystem root which doesn't contain any suid executables. This provides great robustness; a maliciously gained shell now has a much much reduced chance of leading to serious damage. However, like a suid executable, the syscall interface also crosses a privilege boundary. There are a lot of syscalls! In the absence of the ability to hammer on suid executable bugs, a competent attacker must surely turn to the Linux kernel syscall API as a source of boosting their privilege. This is an entirely feasible attack approach - look at the sysctl() and getsockopt() vulnerabilities I found recently. These _kernel_ level bugs are deadly. Suddenly, your lovely MAC module to protect your very sensitive data is useless... and the current LSM hooks would probably not protect against these of other similar bugs. It would be lovely to see the ability to adopt some form of syscall ACL - default deny! Many apps, once up and running, need the use of a very small syscall set. If applied properly, bugs in daemons could tend towards being useless to attackers - no DoS via excessive fork(), brk(), mmap(), etc. No increasing of privilege via exec(), no network abuses with connect(). You can see, the possibilities are interesting. Discussion invited. Cheers Chris _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon May 14 2001 - 16:56:42 PDT