The Least Privilege Model in Solaris 10 allows for finegrained management of process and user privileges within Solaris 10. Amy Rich has written a nice introduction for Sun’s bigadmin website.
The Least Privilege Model in Solaris 10 allows for finegrained management of process and user privileges within Solaris 10. Amy Rich has written a nice introduction for Sun’s bigadmin website.
its too complex and ugly. no thanks
This reminds one of VAX/VMS and its set of privileges, which allowed various partial privileges to computer operators’ accounts, field engineer accounts, backup accounts, etc.
History is progress!
Real security is hard work, but it is getting easier. For example, once I began understanding Solaris 10’s SMF, I really enjoyed disabling inetd and rc.d services with one command line rather than messing around with all the /etc/rc* directories, configuration files, or relying on more complex GUIs to do that for me. Another nice thing is that enabling TCP Wrappers is just one more command to SMF. Also, Solaris 10 has a new super-minimal install for people who don’t want GUIs and just need the basics. There’s also an integrated ipf firewall, which is a lot less resource-intensive than managing SunScreen.
Given that Sun is saying that Trusted Solaris will be only an extention to the regular Solaris (no longer separate products), people can take Solaris pretty seriously for secure environments.
As opposed to SELinux policies? Proper security is often complex and ugly.
Please don’t bring up Linux. When Linux comes up in Sun aticles, it just invites flaming. Let’s just leave Sun alone and they can leave us alone so we all can be happy.
Regarding the Least Privilege Model in the Solaris 10 OS versus SELinux…
Which is best in what ways… Comments?
“As opposed to SELinux policies? Proper security is often complex and ugly.”
I would agree with you in general but my current system using fc3 has selinux enabled by default. so does RHEL4 and it is a pretty smooth sail. no problems at all
SELinux policy files in general have a similarity to the trusted solaris model but the allowance of runtime policy configuration particularly the existence of boolean values and that Red Hat has actively been pushing for it by *default* changes a whole lot of things
They have similar underlying concepts. if you are interested there are docs to learn about SELinux. NSA maintains the kernel parts which work over LSM
Red Hat maintains the userland
http://fedora.redhat.com/docs/selinux-faq-fc3/
http://fedora.redhat.com/docs/selinux-apache-fc3/
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux…
All of the articles are a good read about a very complex subject. In the vast majority of cases this level of security is not necessary, and if improperly implemented could cause more problems than the “security hole” you are trying to fix.
At a recent seminar I asked an engineer from RedHat about SELinux and using Oracle in an OFA compliant installation as an example. He told me that if I wanted to use SELinux with Oracle in RHEL 4 in the example I specified, I would have to write the policy for it since RHEL does not cover Oracle.
In both cases this is not an “out of the box” solution, which will require some serious experimentation and documentation before it is implemented. Which one is better, I wouldn’t say that one is better than the other. It is all a matter of what you want to protect, and how far you are willing to go to do it.
“He told me that if I wanted to use SELinux with Oracle in RHEL 4 in the example I specified, I would have to write the policy for it since RHEL does not cover Oracle”
true
“In both cases this is not an “out of the box” solution, which will require some serious experimentation and documentation before it is implemented.”
its an out of box solution for deamons that selinux protects by default on RHEL 4 but oracle will have to write their selinux policies which they have done and an update will integrate it without any experimentation on your part
lets be very clear about. Third party ISV software will have to write their own policies since they dont provide source code for determining the best path to do it by the distribution
It is not up to the vendor to provide the policy since there are multiple ways of installing a given product, and I am sure vendors do not want to get caught up in supporting something they did not create. What I specified was an Optimal Flexible Architecture (OFA) installation, which uses multiple physical volumes. You can do it with separate mount points, but separate volumes are better for performance reasons. Using either product, you could theoretically limit access to the volumes as part of your policy.
If an organization wants to increase their security posture, THEY are going to have to review and write security policies using either product.
“It is not up to the vendor to provide the policy since there are multiple ways of installing a given product, and I am sure vendors do not want to get caught up in supporting something they did not create. ”
dont be silly. oracle is a ISV partner for Red Hat. when its possible for Red Hat to provide a policy for apache which is one of most flexible and customisable deamons in a Linux system, its entirely possible for oracle to write a selinux policy for its own program with Red Hat’s help and it has already started work on it. you can create customisation points with booleans in the policy. you seem to assume that SELinux is not flexible enough without sufficient exposure to it.
read
http://fedora.redhat.com/docs/selinux-apache-fc3/
”
If an organization wants to increase their security posture, THEY are going to have to review and write security policies using either product.
”
sure but writing selinux policies from scratch is a waste of time and energy. you can review it to make sure it isnt messy and you cannot even do that without the policy sources
while Trusted Solaris is mentioned in the article ppriv in Solaris 10 is technically different. From a Linux perspective it shouldn’t be compare with SELinux but rather with capabilities.
The first post is to me symptomatic for lot of security technology in Solaris. BSM, RBAC, PPRIV, … are real goods piece of tech to improve site security but only very few use it. I think SELinux does belong to this category. In theory you have even to define first the security model.
For now it is to me only a very clever marketing move from redhat. Don’t forget that alone the integration of sec tools in an OS doesn’t mean per se any improvement (think PAX, gsrsecurity,…)
So is that another way of saying “but the lightbulb has to want to be secure” ?
My personal opinion on the least privileges stuff is that
given the massive effort towards complying with privacy
legislation and corporate governance stuff (SOX et al), it
will be a nice surprise for suits when they realise that the
security features they need are integrated into the base or
“no frills” version of solaris 10 and they don’t have to
pay extra for it.
When the suits get enthused, the admins will get enthused,
because the admins will realise that they don’t need to go
through another round of purchasing approvals and dedicated
system tests in order to comply with management edicts.