Agreed in principle. The biggest security complaint I have with Unix/Linux is the limitations of the built-in security model. It would be nice to have a more secure default model in the kernel (SELinux does this, it's access controls are added to the kernel), but the wider Linux community hasn't embraced this concept so far. That limitation is part of what keeps Linux out of a lot of sensitive environments (Military, Finance, etc...) where FIPS/CC certification is required.
==Joseph++
P.S. What's the URL for GRSEC??
slegge@govliquidation.com wrote:
> Another good implementation of securing access to system as a whole is
> GRSEC (using Role Based Access Control "RBAC"). Its infinitely granular
> restricting system calls and what hardware is accessed by whatever you
> configure. I know it sounds complex at first.. thats because it is but IMO
> a great addition to the fairly loose kernel. The thing is once you have a
> system setup you can copy its configuration and deploy as necessary. At
> the end of the day all the ACL in the world are useless when a user can
> run the (right/wrong) suid app (or other arbitrary code) and compromise
> all system integrity. IMO ACL are a waste of time when the entire system
> is compromised. When a chroot() can be broken from some other flawed or
> uncontrolled system call and gain root access whats the point?
>
>
>
> -Scott
>
>
> Joseph Sinclair <plug-discuss@stcaz.net>
>
> SELinux is a modified kernel (and some other parts of the GNU/Linux
> system) to support better security, including native ACL-like support,
> mandatory access control (no root user!), and policy-based security
> enforcement.
> ACL's (short for Access Control List) are a mechanism whereby multilayered
> access controls are applied to operating system objects, SELinux actually
> uses policies, but it works the same, for the most part.
> In Linux (as with all Unix-like systems) everything is a file, so ACL's
> are mostly applied to files.
>
> Technically, SELinux adds role-based security with mandatory access
> controls to a Linux system, not ACL's. It's a fine point, but it explains
> why setting up security is easy in Windows, and a serious PITN on SELinux.
>
> SELinux is the "standard" distribution that supports using enhanced
> security in a GNU/Linux environment, without it, you won't, usually, have
> anything like ACL's to work with.
> If you can get ACL's without SELinux, DO SO, SELinux is serious extra work
> if all you need is multilayered access control.
> I did a bit more research on this, and there is ACL support available for
> most Linux filesystems, but the support within the filesystem tools may be
> lacking, and if the ACL support
> isn't compiled into the kernel (many distros don't include it), then it's
> just not available, whether the FS supports it or not.
>
> For ACL resources:
> There's an outdated article on this at (
> http://www.suse.de/~agruen/acl/linux-acls/online/)
> Here's the about.com entry for ACL (
> http://linux.about.com/library/cmd/blcmdl5_acl.htm)
> Here's an ACL management tool that might help (
> http://www.ameba6.com/guiaclmanager/)
> Fedora Core 4 should have ACL's compiled in the kernel and most
> filesystems. Check if getfacl is present on your system, I don't have a
> FC4 system to try this on.
>
> More on SELinux at (http://www.nsa.gov/selinux/) (Note, this is the US
> National Security Agency, standard caveats apply).
> SELinux is generally incorporated into the 2.6 kernels and just not
> enabled by default.
> Fedora Core incorporates an SELinux mode, the FAQ for FC3 is at (
> http://fedora.redhat.com/docs/selinux-faq-fc3/index.html), they haven't
> put up the FAQ for FC4 yet, but SELinux is definitely there, and
> considerably improved.
>
> SELinux installs tend to take quite a bit of time to get right, so I would
> plan on a few weeks, at least, to get it all set up before exposing users
> to it, since any problems with the security policy can completely alienate
> the user base in negative time.
>
> ==Joseph++
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change you mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)