Bug was filed and closed due to duplication. This is a known problem.
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
I'm in total agreement from a security aspect (recall
that OpenSolaris's
roots are in the enterprise server world and not
wide open desktop
land). I would ask you why root shouldn't be a role?
Hopefully the
nswer won't involve convenience.
In making root a role you now rely on a user
On Fri, Jul 30, 2010 at 03:49:57PM -0700, David
Brodbeck wrote:
On Jul 30, 2010, at 3:31 PM, Scott Rotondo wrote:
Regarding the expansion of the attack surface,
remember that assuming the root role requires logging
in to a user account first and then providing the
root password.
This is a variant of the convenience argument.
Systems with root as a
ole require a local user account with Primary
Administrator role. When
I installed OpenSolaris it did the right thing and
created such an
account that does not depend on NIS or LDAP and is
thus insulated from
issues
Bayard Bell ha scritto:
One basic argument for converting root to a role is that logs no longer reflect
root did it, where that's someone logged in as root–what you are now able to
determine is whodunnit exactly using a level of privilege rather than accessing an
account, which doesn't make
On Aug 2, 2010, at 5:00 AM, Mike DeMarco wrote:
This is a variant of the convenience argument.
Systems with root as a
ole require a local user account with Primary
Administrator role. When
I installed OpenSolaris it did the right thing and
created such an
account that does not depend on
On Fri, Jul 30, 2010 at 04:51:57PM -0700, David Brodbeck wrote:
On Jul 30, 2010, at 4:41 PM, Will Fiveash wrote:
On Fri, Jul 30, 2010 at 03:49:57PM -0700, David Brodbeck wrote:
On Jul 30, 2010, at 3:31 PM, Scott Rotondo wrote:
Regarding the expansion of the attack surface, remember
jimwtype=normal;profiles=File System
Management,ZFS File System Management
which doesn't give jimw the ability to su to root but
does give some,
but not all, additional privs when he pfexec's
commands.
I know that this is only an example but I prefer using zfs allow to grant zfs
On Aug 2, 2010, at 5:00 AM, Mike DeMarco wrote:
This is a variant of the convenience argument.
Systems with root as a
ole require a local user account with Primary
Administrator role. When
I installed OpenSolaris it did the right thing and
created such an
account that does not
From an audit perspective, it's still going to show the activity as
uid 0 vs an actual user. With the right infrastructure, it then
becomes a lot harder to subvert...
..now if Oracle's others products (E-Biz suite) would actually work
properly in an rbac environment...
On Mon, Aug 2, 2010 at
On 08/ 2/10 03:02 PM, Jason wrote:
From an audit perspective, it's still going to show the activity as
uid 0 vs an actual user.
The idea is that one can track which user assumed the root role, and
thus can associate the activity with a user.
-Seb
On Mon, Aug 02, 2010 at 11:31:31AM -0700, Mike DeMarco wrote:
jimwtype=normal;profiles=File System Management,ZFS File System
Management
which doesn't give jimw the ability to su to root but does give
some, but not all, additional privs when he pfexec's commands.
I know that this
On 07/30/10 03:49 PM, David Brodbeck wrote:
On Jul 30, 2010, at 3:31 PM, Scott Rotondo wrote:
Regarding the expansion of the attack surface, remember that
assuming the root role requires logging in to a user account first
and then providing the root password.
Well, yes and no. It's true
On 08/ 2/10 04:55 AM, Mike DeMarco wrote:
In making root a role you now rely on a user account to be available
at all times. You can not login as the role and if the user account
gets misconfigured in some way you can not login at all. User
accounts are fluid they grow and get configured in
You may want to read up on the ancient Unix idea of setuid root software
before making such proclamations.
Sorry for this. I am not a UNIX guru, indeed.
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
Build 134:
1) Could anyone please explain why root has been converted to a role. I would
venture a guess that someone somewhere believes that it is more secure to run
root as a role. The whole if root can not log directly into the box than
someone can not crack the root password. Well I agree
sound-juicer is started by a non-root user the process runs as root and writes
its files as root
If this is true, this is a huge security hole. Someone should investigate the
problem. As far as I could understand, Sound Juicer does not know root
password, however bypassing this somehow. Total
Dmitry G. Kozhinov d...@desktopfay.com wrote:
sound-juicer is started by a non-root user the process runs as root and
writes its files as root
If this is true, this is a huge security hole. Someone should investigate the
problem. As far as I could understand, Sound Juicer does not know
Since sound-jouicer now cleanly calls cdda2wav in
order to read AUDIO data from
CD, there should no longer be a need to run
sound-juicer as root.
looks like it is rmvolmgr that starts sound-juicer when a cd is inserted and it
asks if you want to start CDripper. Since rmvolmgr runs as root
Sound-juicer is not suid-root; probably the Gnome application definition starts
it elevated.
If one starts it from the command line, one cannot see the CD device. Prepend
it with pfexec, it works (as long as you have the role, of course).
So no, it is a security risk as much as anything in
Dmitry G. Kozhinov wrote:
As far as I could understand, Sound Juicer does not know root password,
however bypassing this somehow. Total crash of all UNIX ideas.
You may want to read up on the ancient Unix idea of setuid root software
before making such proclamations.
--
-Alan
Very troubling that this kind of vulnerability goes unchecked. How many others
are in the mix?
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
On 07/30/10 01:26 PM, Mike DeMarco wrote:
Since sound-jouicer now cleanly calls cdda2wav in order to read
AUDIO data from CD, there should no longer be a need to run
sound-juicer as root.
looks like it is rmvolmgr that starts sound-juicer when a cd is
inserted and it asks if you want to start
On Jul 30, 2010, at 10:57 AM, Mike DeMarco wrote:
Very troubling that this kind of vulnerability goes unchecked. How many
others are in the mix?
I agree that this should be fixed, but let's not overreact; this is a program
designed to be run by a local user at the console. If someone's at
I agree that this should be fixed, but let's not
overreact; this is a program designed to be run by a
local user at the console. If someone's at the
console they can already own your machine at will
just by booting a LiveCD and mounting your
filesystems.
This is true, but it still writes
I just submitted a security bug on this.
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Bug id 16693
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
On Fri, Jul 30, 2010 at 04:59:57AM -0700, Mike DeMarco wrote:
Build 134: 1) Could anyone please explain why root has been converted
to a role. I would venture a guess that someone somewhere believes
that it is more secure to run root as a role. The whole if root can
not log directly into the
On 07/30/10 04:59 AM, Mike DeMarco wrote:
Build 134: 1) Could anyone please explain why root has been converted
to a role. I would venture a guess that someone somewhere believes
that it is more secure to run root as a role. The whole if root can
not log directly into the box than someone can
On Jul 30, 2010, at 12:26 PM, Will Fiveash wrote:
I'm in total agreement from a security aspect (recall that OpenSolaris's
roots are in the enterprise server world and not wide open desktop
land). I would ask you why root shouldn't be a role? Hopefully the
answer won't involve convenience.
On Fri, Jul 30, 2010 at 12:44:43PM -0700, David Brodbeck wrote:
On Jul 30, 2010, at 12:26 PM, Will Fiveash wrote:
I'm in total agreement from a security aspect (recall that OpenSolaris's
roots are in the enterprise server world and not wide open desktop
land). I would ask you why root
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/30/2010 4:24 PM, Will Fiveash wrote:
On Fri, Jul 30, 2010 at 12:44:43PM -0700, David Brodbeck wrote:
On Jul 30, 2010, at 12:26 PM, Will Fiveash wrote:
I'm in total agreement from a security aspect (recall that OpenSolaris's
roots are in the
On Fri, Jul 30, 2010 at 04:33:47PM -0400, Kyle McDonald wrote:
On 7/30/2010 4:24 PM, Will Fiveash wrote:
On Fri, Jul 30, 2010 at 12:44:43PM -0700, David Brodbeck wrote:
On Jul 30, 2010, at 12:26 PM, Will Fiveash wrote:
I'm in total agreement from a security aspect (recall that
On Fri, Jul 30, 2010 at 02:05:03PM -0700, David Brodbeck wrote:
On Jul 30, 2010, at 1:33 PM, Kyle McDonald wrote:
I actually like root as a role, but it strikes me that by forcing all
machines to have a single local user with a pw that everyone knows,
you've totally re-opened the hole
Another solution would be if the network service (NIS, LDAP) client
supported some form of local caching when disconnected from a server
(sounds like a good RFE :P).
On Fri, Jul 30, 2010 at 4:31 PM, Will Fiveash will.five...@oracle.com wrote:
On Fri, Jul 30, 2010 at 02:05:03PM -0700, David
This is slightly off topic, but somewhat related... one of the advantages sudo
has over pfexec is that by default it asks you to re-enter your password before
dishing out extra privileges.
Is there an argument for adding this to pfexec?
From my experiences, sysadmins that have to administrate
On Fri, Jul 30, 2010 at 04:31:02PM -0500, Will Fiveash wrote:
I will modify what I wrote earlier about about OpenSolaris requiring a
local user account that can assume the primary admin role by stating
that I may have been wrong about this being required. Certainly it can
be useful to have
On 07/30/10 02:05 PM, David Brodbeck wrote:
On Jul 30, 2010, at 1:33 PM, Kyle McDonald wrote:
I actually like root as a role, but it strikes me that by forcing
all machines to have a single local user with a pw that everyone
knows, you've totally re-opened the hole that this was supposed to
One basic argument for converting root to a role is that logs no longer reflect
root did it, where that's someone logged in as root–what you are now able to
determine is whodunnit exactly using a level of privilege rather than accessing
an account, which doesn't make various auditors very
On 07/30/10 12:44 PM, David Brodbeck wrote:
This *can* be worked around by making sure every machine has a valid
local user with access to the root role -- sort of. pfexec becomes
extremely slow if you have incorrectly configured LDAP -- as in
several minutes of waiting to run a single command.
Not only configurable, but tunable as well -- you can configure how
many times it tries to query a backend, and what to do based on the
result from the backend.
I'd need to check the nss_ldap code, but last time I looked (which was
a _long_ time ago, so very possible it changed, especially since
On Jul 30, 2010, at 3:31 PM, Scott Rotondo wrote:
Regarding the expansion of the attack surface, remember that assuming the
root role requires logging in to a user account first and then providing the
root password.
Well, yes and no. It's true that su requires the root password, and sudo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/30/2010 4:54 PM, Will Fiveash wrote:
On Fri, Jul 30, 2010 at 04:33:47PM -0400, Kyle McDonald wrote:
On 7/30/2010 4:24 PM, Will Fiveash wrote:
On Fri, Jul 30, 2010 at 12:44:43PM -0700, David Brodbeck wrote:
On Jul 30, 2010, at 12:26 PM, Will
On Fri, Jul 30, 2010 at 03:49:57PM -0700, David Brodbeck wrote:
On Jul 30, 2010, at 3:31 PM, Scott Rotondo wrote:
Regarding the expansion of the attack surface, remember that assuming the
root role requires logging in to a user account first and then providing
the root password.
On Jul 30, 2010, at 4:41 PM, Will Fiveash wrote:
On Fri, Jul 30, 2010 at 03:49:57PM -0700, David Brodbeck wrote:
On Jul 30, 2010, at 3:31 PM, Scott Rotondo wrote:
Regarding the expansion of the attack surface, remember that assuming the
root role requires logging in to a user account
On Fri, Jul 30, 2010 at 07:37:43PM -0400, Kyle McDonald wrote:
On 7/30/2010 4:54 PM, Will Fiveash wrote:
On Fri, Jul 30, 2010 at 04:33:47PM -0400, Kyle McDonald wrote:
On 7/30/2010 4:24 PM, Will Fiveash wrote:
On Fri, Jul 30, 2010 at 12:44:43PM -0700, David Brodbeck wrote:
On Jul 30,
The LDAP code is much more sophisticated that it once was,
especially as it applies to the management of connections and
LDAP server connection failure situations.
If LDAP naming is enabled, and access to a server is unavailable
the system is expected to respond properly and not hang on lookups.
47 matches
Mail list logo
