SELinux vs. AppArmor vs. Standard vs. What?

Fri Oct 31 20:32:59 MST 2008

Lisa, that was an interesting post.

On Fri, Oct 31, 2008 at 10:28 PM, Lisa Kachold <lisakachold at obnosis.com>wrote:

>
> Hi Alan!
>
> You are not sending this out to your customer at consultpro.com are you?
>  Laugh?  That's okay, I am used to teaching open source solutions!
>
> The question as to what level of security is needed is definitely specific
> to the use and exposure.
> You will have risk in this remote desktop solution.  It can be a point of
> entry to your entire operation.
>
> While you will be giving trust, you will not want privileges escalated by
> accident or through interception of a password/pair and nepharious C buffer
> exploits via remote access.
>
> VPN's can be hijacked; logins can be socially engineered; Blackberry and
> phone systems "password safe" can be displayed through Bluetooth and/or
> clearly accessed from backups on home Windows systems.  [Not all users,
> necessarily know that their $shares are PUBLIC - so anyone on the same
> wireless can cruise through their files].
>
> Employees pre-gruntle, will setup backdoors, then trade logins on IRC
> groups after exit and worse.
> It's not ethical to allow people trust where they are incapable of carrying
> that burden.
>
> To protect against losing ownership, as you said, a great many tools are
> implemented by saavy systems engineer/administrator.  IpSec is a complete
> science wherein use is identified with identification of solutions to
> mitigate risk and potentiate reward; but we will leave those lectures for
> another exercise.
>
> In Fedora SELinux is fairly painless and includes Wizards for setup and
> resolution of errors.
> In Novell's Suse, AppArmour is painless and includes extensive low level
> kernel changes to protect against risks like non-exec stack patches [like
> Pax and ExecSheild] (developed initially as Immunix by Crispen Cowen).
>
> You can also add ExecShield:  http://kerneltrap.org/node/644
> or
> Pax:  http://pax.grsecurity.net/http://pax.grsecurity.net/
> Which protect the kernel against various types of EXEC functions.
>
> These are EASY solutions - unless the server changes regularly they will
> just work!
>
> Other recommendationsIt's not ethical tIt's not ethical to allow people
> trust where they are incapable of carrying that burden to allow people trust
> where they are incapable of carrying that burden.u
>
> 1) Consider running as an XEN virtual in a PAE kernel.  Users or exploiters
> will just break your XEN kernel and not the "real one";  Your disaster
> recovery post encroachment is a trivial matter of backing off user
> directories and recreating a new XEN kernel.
>
> 2) Be sure that your deliniation between production public and development
> is punctuated with a COMPLETE BACKUP and CRC check of the binaries.
>
>
> http://serverlinux.blogspot.com/2005/11/binaries-changing-size-in-fedora-core.htm
> http://www.codebreakers-journal.com/content/view/45/27/
>
> Setup a regular check via Cron to ensure there have been no serious changes
> to CRC = tripwire does this.  Or use a simple file find - diff shell script.
>
> Tripwire must be run and configured after build before the system goes
> production to be of any real use!
>
> 3)  Disable and/or change permissions for all but essential tools for
> users.
>
> pam.d and sudo are not going to assist you to keep your users from ssh-ing
> to localhost, or nmap scanning your network, or overflowing binaries then
> mailing out their results, but file permissions will assist.
>
> You can  also even give users a restricted shell, depending on what they
> need to do?
> http://www.vias.org/linux-knowhow/bbg_sect_01_02b_10.html
>
> They can't change directory or list files depending on the way you
> implement it.
>
> 4) Harden: (Distro-dependent)
>
> a) Remove all but essential packages, turn off all but essential services
> (bluetooth/cupsd/lisa/samba), turn down X, (you can run startx later),
> configure the semaphores.
>
> http://www.linux-tutorial.info/modules.php?name=MContent&pageid=291
>
> http://packetstormsecurity.org/linux/admin/lasg-0-1-7.pdf
>
> Tripwire must be run and configured after build before the system goes
> production to be of any real use
>
> b) Verify versions of everything you add on - beit OpenSwan or NX VPN
> tools, each version has known issues.
>
> Even using a non-secure Firefox 2.0 without controls to troubleshoot your
> "server" can open a HUGE door, should you click on a Javascript XSS URI or
> open an email with an UTF encloding exploit somewhere while searching for a
> solution.
>
> 5) Patch initially and regularly - THIS IS VERY IMPORTANT!!!!!!
>
> 6) Use IPTABLES - so that they can't easily setup a SSH tunnel BACK to
> their house running on a unattended open port.  This means you ONLY accept
> your VPN NX packets etc.  and THAT IS all.  You can trivially setup this in
> SUSE using their 3 zone firewall setup utilities.  Fedora Core also has
> extensive examples available that you can tailor to your needs.
>
> 7) Scan test your system with a good pentest tool.  Be sure you nmap from
> external IP to verify what you think is closed and what you think is
> configured correctly is REALLY so!
>
> ASSUME nothing!
>
> 8) Follow PCI Compliance and Sarbanes/Oxley recommendations:
>
> Use secure passwords [8 characters - do not set "passw0rd" as the starting
> temporary password
> Require password aging and changes regularly (automate it)
>
>
> May the source be with you, young Jedi night!
>
> http://wapedia.mobi/en/Obnosis |
> http://en.wiktionary.org/wiki/Citations:obnosis | Obnosis.com
> (503)754-4452Laugh at this MSN Footer
>
> ----------------------------------------
> > Date: Fri, 31 Oct 2008 16:19:00 -0700
> > From: alandd at consultpros.com
> > To: plug-discuss at lists.plug.phoenix.az.us
> > Subject: SELinux vs. AppArmor vs. Standard vs. What?
> >
> > Thanks for all the responses to my remote desktop login question.  I'm
> > pretty sure we will deploy FreeNX for that function.
> >
> > This question has to do with the same server.  A tech savvy manager
> > says we should use "NSA Linux" on the remote desktop host server.
> > What he means is use the SELinux security features.
> >
> > Now, I don't have lots of experience with setup and maintainence of
> > SELinux.  I hAve read that it is painful and requires more
> > administration than just "set and forget."
> >
> > A similar technology is the AppArmor profiles for applications.  Said
> > to be easier to use than SELinux but provides much the same benefits.
> >
> > Then a third camp seems to think that both of these are overkill and a
> > headache for the benefits gained.  They feel that, configured
> > correctly, standard user security on a Linux box is secure enough for
> > most business applications.
> >
> > Where do any of you stand on this argument?  Is SELinux really a pain
> > to setup and use?  Is AppArmor interesting but not worth it?
> >
> > Given the function of the server as I previously described in that
> > other thread (
> http://lists.plug.phoenix.az.us/lurker/thread/20081030.230820.05346d48.en.html#20081030.230820.05346d48
> ),
> > What security extensions would you deploy and why?
> >
> > Alan
> > ---------------------------------------------------
> > PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> > To subscribe, unsubscribe, or to change your mail settings:
> > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
> _________________________________________________________________
> You live life beyond your PC. So now Windows goes beyond your PC.
> http://clk.atdmt.com/MRT/go/115298556/direct/01/
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>

-- 
:-)~MIKE~(-:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20081031/6b1652e8/attachment.htm 