In my opinion, apart from technicalities, this discussion shows the very
critical point of security.
Let me shortly try to expose the point.
Security targets for a given system can greatly vary, depending on the
usage context of the system, its tasks, and its surrounding environment.
And there will never be a security policy/configuration which encompasses
all usage scenarios.
Also if we suppose than the considered system were equipped with the
"perfect set of security tools and mechanisms", there will be the
problem of choosing the right system configuration and of doing a careful
system management.
Thus, the security of a system strongly relies upon user's awareness and
knowledge of the set of security tools
and mechanisms offered by the system. The odd here is that adding
security features to a systems usually makes the system configuration
and administration more difficult....
(Open)Solaris offers undoubtedly state-of-the-art security features, but
the very problem in the next years will be to have (Open)Solaris users
that will able to use appropriately their boxes.
I think there are two keywords in order to get that, and two related
challenges for Sun-Oracle
(and our community).
*Easy-of-use*
The main road to get secure system configurations is to provide
easy-to-use user interfaces, and straight installation and
administrative workflows. I think there is still a lot of work to do in
such respect, both for
Solaris and Opensolaris.
However, also if the system interface was carefully designed with to
easy-of-use in mind, the many subtleties concerning security would led
to a system intrinsically difficult to manage. The more the security
features
offered by the system and its flexibility, the more the subtleties.....
Thus, the last but not least keyword is
*Knowledge*
The open(solaris) documentation has greatly been improved in the last
years, both in quantity and quality,
but a lot of work has to be done to easy the access to technical
information and to facilitate its comprehension
(not only for dummies). More concrete examples and use cases can
ameliorate the actual state. Also, a revision
of the approach in realizing and presenting man pages and (some) on-line
documentation should be taken into account
But, apart from documentation, the diffusion of knowledge and the growth
in expertise can be only obtained if a
strong feedback between the software vendor, Academia, and Industry is
put in place.
My teaching experiences in these last years indicate that the model
"opensolaris as driver of solaris" is giving its
fruits, and that many others could be reached in the future. I hope
Oracle is going to prosecute on the road path
smartly initiated in this respect at Sun. In the open networking Era,
security can neither be afforded nor sustained without an open-source
business model.
giovanni
Giovanni Schmid, PhD.
National Research Council
Italy
Darren Reed ha scritto:
On 3/08/10 11:05 PM, Scott Rotondo wrote:
On 8/3/10 10:49 PM, Darren Reed wrote:
On 3/08/10 10:21 PM, Scott Rotondo wrote:
On 8/3/10 7:26 PM, Darren Reed wrote:
Last time I tried, I could not su to root because it was a role.
You are mistaken. When root is a role, su is the *only* way to log in
to that account. Of course, your user account must be authorized to
assume that role.
My recollection is that when I tried to do "su" from the created
account
it failed with an error that was the same as when I tried to login
to the
root account - i.e. that it was not permitted because root was a role.
You must have tried this from a user account that does not have root
in its list of allowed roles. Try running roles(1) first.
Let me guess, the first account created gets put in the "Primary
Administrator" role and not the "root" role?
(I don't have the respective system handy...)
Darren
_______________________________________________
security-discuss mailing list
[email protected]
_______________________________________________
security-discuss mailing list
[email protected]
