Hi, Yesterday night, the first release of vSecurity was made publicly available at tuxedo-es.org cvs, which can be found at: http://cvs.tuxedo-es.org/cgi-bin/viewcvs.cgi/vsecurity/ As a short introduction, "vSecurity is a new approach to Linux kernel security inspired and partially based on grSecurity, using the Linux Security Modules framework, improving and bringing several security enhancements in a non-intrusive manner to the Linux kernel sources." I was working on it since the thread about Linux kernel security ramped into a "flame", without giving things so clear for those who only wanted to know what was the final decision (and the kernel hackers thoughts) on it. During the (around) 3 weeks that it needed to be at least more stable and well-documented (regarding the source code comments and not a technical paper explaining it, which is going to be finished and published ASAP) code, I knew that, in most cases, some of the typical security faults that happen to Linux users could be solved without using much more than the LSM and a well designed engine using it and adding hooks on those places where we can catch up the "exploitation" of the security faults. vSecurity currently protects (in a "Plug & Play" manner) against: - Execution (mmap()'ing in elf_map()) of binaries in untrusted paths. (and also protection against tricky uses of mprotect() to bypass such protections, which are formerly known as Trusted Path Execution, TPE). - BSD Jails implementation, based on Serge Hallyn's code. - Chroot() Jails (even if they are broken by design *sigh*) protections. (Basic anti-escaping: double chroot()'ing, etc, a few capabilities protections, etc.IPC and SHM protections are not yet implemented, also setuid bit protections are not yet implemented too). Anyways, I encourage to use the BSD Jails functionality instead of simple chroot() jails. (An userland support tool for change namespaces, "auto" jailing, is going to be available as soon as Serge and me finish it, that will help on BSD Jails use automation). - Linking protections: symlinking and hardlinking,FIFOs not yet in 0.1-cvs. - Socket restrictions: per-socket-type style restrictions: "server" sockets, "client" sockets and all-sockets.Supports per-GID and per-UID configuration basis, prepared for kernel-configuration time and if module is compiled outside and separate of the kernel, with module parameters, same as TPE protections). (Using an ACL engine relying on a sysfs subsystem "secfs"). - RAW I/O protections and kernel symbols protections. (No so-called live-patching for a while :) ) - RLIMIT_NPROC enforcing, check also in fork() calls so ulimits will apply and checked each call to know if user can do it or not). Native and enhanced support in BSD Jails (which also have Serge's "network virtualization" engine. Useful against so-called fork() bombs. - Other enhancements and security improvements. It's not as mature as I want, but I decided to release it as soon as possible to get feedback, bug reporting (sure it has, we all do mistakes ;) ), etc. Please, keep in mind that It's a development release, I wouldn't like to receive comments about "how a big crap is this" and such, until a stable release gets finished :). Code is well-documented, but as I commented a few lines above, I will make available a paper explaining it further, ASAP. Also, I would like to thank Seth Arnold from Immunix for helping me with my (again) extensive lack of knowledge, Serge Hallyn from IBM for helping with BSD Jails code and testing, suggestions, etc, Stephen Smalley for his suggestions, comments and help on some protections implementation, Brad Spengler for helping when I asked about some grSecurity pearls, and David B. Harris from OFTC (and whole OFTC staff) for hosting my crap there :). I hope this would be useful and interesting, and, again, I would appreciate any feedback on it. Thanks in advance, enjoy it. -- Lorenzo Hernández García-Hierro <lorenzo@private> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
This archive was generated by hypermail 2.1.3 : Sun Jan 30 2005 - 05:39:34 PST