On Thu, Oct 01, 2009 at 11:18:33AM -0300, gilberto alves wrote: > In my opinion these very, very, very detailed email spend more time that > running same application in new environment centos 5xx? Definitely. > Here in Brazil quickly we adopted this new version and lots of > application running very ok. Yes, but on a full-blown CentOS 5 install, not on Owl. This mailing list is about uses of Owl. Owl may be preferred over CentOS for the "base system" for a variety of reasons, including security. Are you able to run a CentOS system with not a single SUID program (each one of them poses a risk!), where users would nevertheless be able to change their passwords, setup cron jobs, etc? No, that's not possible with CentOS alone. However, it is possible with Owl, and it remains possible with Owl plus a few CentOS packages (for specific components needed on a given install but missing from Owl). (As discussed, custom builds for the missing components may work better, though.) Then, suppose you have your SSH port available for connections by the users (e.g., of your web hosting server). Under CentOS 5, "sshd" is linked against 25 libraries, many of which sound risky/scary to me. Under Owl, this is reduced to 12 libraries, most of which are tiny and relatively low risk. I include the specific library lists below to better illustrate my point. That's just two examples. CentOS 5: [root_at_host ~]# ldd /usr/sbin/sshd libwrap.so.0 => /usr/lib64/libwrap.so.0 (0x00002b53487e8000) libpam.so.0 => /lib64/libpam.so.0 (0x00002b53489f1000) libdl.so.2 => /lib64/libdl.so.2 (0x00002b5348bfc000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b5348e01000) libaudit.so.0 => /lib64/libaudit.so.0 (0x00002b5349019000) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002b534922d000) libutil.so.1 => /lib64/libutil.so.1 (0x00002b5349576000) libz.so.1 => /usr/lib64/libz.so.1 (0x00002b5349779000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00002b534998d000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b5349ba6000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00002b5349dda000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002b5349fef000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002b534a21e000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002b534a4b0000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002b534a6d5000) libnss3.so => /usr/lib64/libnss3.so (0x00002b534a8d8000) libc.so.6 => /lib64/libc.so.6 (0x00002b534ab60000) /lib64/ld-linux-x86-64.so.2 (0x00002b53485cd000) libsepol.so.1 => /lib64/libsepol.so.1 (0x00002b534aeb0000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002b534b0f7000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002b534b2ff000) libplc4.so => /usr/lib64/libplc4.so (0x00002b534b502000) libplds4.so => /usr/lib64/libplds4.so (0x00002b534b707000) libnspr4.so => /usr/lib64/libnspr4.so (0x00002b534b90a000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b534bb44000) [root_at_vz3 ~]# ldd /usr/sbin/sshd | wc -l 25 Owl: host!root:~# ldd /usr/sbin/sshd libwrap.so.0 => /usr/lib64/libwrap.so.0 (0x00002ab426de6000) libpam.so.0 => /lib64/libpam.so.0 (0x00002ab426eef000) libdl.so.2 => /lib64/libdl.so.2 (0x00002ab426ffc000) libutil.so.1 => /lib64/libutil.so.1 (0x00002ab4270ff000) libz.so.1 => /usr/lib64/libz.so.1 (0x00002ab427203000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00002ab427317000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002ab42742d000) libpam_misc.so.0 => /lib64/libpam_misc.so.0 (0x00002ab427579000) libpam_userpass.so.1 => /usr/lib64/libpam_userpass.so.1 (0x00002ab42767c000) libcrypto.so.5 => /lib64/libcrypto.so.5 (0x00002ab42777d000) libc.so.6 => /lib64/libc.so.6 (0x00002ab4279bd000) /lib64/ld-linux-x86-64.so.2 (0x00002ab426cd1000) As you can see, the Owl list is much shorter (and the libraries are much smaller). No Kerberos, no SELinux, no audit - but seriously, do those help improve security? Hardly. Not for most installs. But they pose a risk, a lot of it. Now, why we're discussing Owl plus CentOS 4 packages rather than Owl plus CentOS 5 packages? Simple: unfortunately, Owl does not provide sufficient compatibility for RHEL 5 / CentOS 5 packages yet. In fact, we're likely to "jump over" RHEL 5 userland compatibility, moving from the current partial RHEL 4 compatibility to partial RHEL 6 / CentOS 6 compatibility (shortly after RHEL 6 release). Alexander -- To unsubscribe, e-mail owl-users-unsubscribe_at_private and reply to the automated confirmation request that will be sent to you.Received on Thu Oct 01 2009 - 07:48:50 PDT
This archive was generated by hypermail 2.2.0 : Thu Oct 01 2009 - 07:49:15 PDT