[ANNOUNCEMENT] vSecurity 0.1-cvs available publicly

[ANNOUNCEMENT] vSecurity 0.1-cvs available publicly

[Lorenzo Hernández García-Hierro]

[-- Attachment #1: Type: text/plain, Size: 4213 bytes --]

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@gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]