I also agree, but even in small business settings where FIPS/CC certification
is not required, even in offices where everyone is a domain admin, and any
security is better then nothing, Linux still is overlooked because no one in
the office can afford the time to figure out complex policies and archaic
command line commands. We would still need a standard set of user-friendly
configuration tools. When I suggest adding another internal file server to
our net work here at work, they rejected the Linux proposal because they felt
I would be the only one who could possible administer it.
Speaking of which (good GUI tools) I looked at the one Joseph recommended for
ACL, despite not having any work done on it in years, it looked exactly like
what I needed; however I could not get it to run on any of my three boxes. It
chokes out importing the python acl module, which I installed using RPM's.
Quoting Joseph Sinclair <
plug-discuss@stcaz.net>:
> 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
>
---------------------------------------------------
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)