On Tue, Aug 10, 2010 at 2:50 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
On Tuesday 10 August 2010 15:03:19 Kevin O'Gorman wrote:
> On Mon, Aug 9, 2010 at 6:18 PM, William Hubbs <williamh@gentoo.org> wrote:
> > On Mon, Aug 09, 2010 at 05:30:40PM -0700, Kevin O'Gorman wrote:
> > > On Mon, Aug 9, 2010 at 1:20 PM, Bill Longman <bill.longman@gmail.com>
> >
> > wrote:
> > > > I actually prefer "sudo su -" -- as long as I'm giving it away! *
)
> >
> > Afaik, there is no reason for "sudo su -" *It should be either
> >
> > su -
> >
> > or, if you are using sudo,
> >
> > sudo -i
> >
> > The disadvantage of "su -" is that it requires the user to know the root
> > password. *But, "sudo -i" does the same thing without requiring the user
> > to know the root password.
> >
> > You either didn't think or didn't actually try it. * "sudo su -" needs a
>
> password, but it's the
> user password. *Running su as root never needs a password. *Accordingly,
> this works on
> a stock Ubuntu with no root password.
>
> "su -" requires the root password unless you're already root, and the root
> password may or may not exist.
>
> I didn't know about "sudo -i" (thanks), but when I tried "sudo -i" it
> immediately asked for a password, for which
> the user password was sufficient. *So it's entirely equivalent to but
> slightly shorter than my version. *I'll stick with
> mine because it's made of parts I already know and won't forget.
>
> I think that if sudoers don't need to enter passwords, they're still
> equivalent, but I have *not tried this.
Sounds to me like he's whinging about sudo and not much else. I find this to
be common and far too *many people advancing the idea can't define to me basic
security concepts. I have also yet to meet someone with a beef against sudo
that can show a fundamental weakness with it, and I'm not talking about an
isolated case of buffer overflow either - that can happen with any software. I
mean a weakness in the methodology of sudo itself.
Many people have a stuck idea in their heads that the root password is a magic
security bullet. In fact, it's no such thing. Like any other password it is
simply something you need to prove you know in order to to authenticate
yourself. The major threat by analysis on a workstation is stepping away for a
leak and forgetting to lock the screen. sudo is adequate protection against
this as long as more than 5 minutes have elapsed since the last sudo was run -
the prankster may have access to the machine but still does not know any
password, including yours. A major threat to finding passwords is shoulder
surfing. If one frequently enters the root password, it is equally easy for a
shoulder surfer to find it as to find the user's password. Note that if you
leave your workstation unlocked with a root session open, there is no such
timeout as what one has with sudo.
Additionally, on a shared machine (i.e. server at work), the root password has
to be shared which is a huge hole in itself due to the difficulty of
communicating the new password when it is changed. It is trivially easy to
communicate a single password for a single user and guarantee it stays secure
(major advances in cryptanalysis excepted).
--
alan dot mckinnon at gmail dot com
Good Luck getting people to change them frequently and haveing your techs and it departments meeting complexity and length policy.
Remeber the only secure system is off and disconnected.
If you are willing to use it you must apriase the community of the risk of failure; and plan for said risk.
Most projects I've enjoyed had various password books usually encrypted with a "God" key for each department and it's respective responsbile area.
Then those keys become an issue in and of themselfs; then it's a matter of procedural control. When the admin or admins leave, change them.
Sounds simple, but far too rarely as it happens in pratice that I've headed to a client I haven't visited in a decade or so and find the same password I once used by guessing.
Wich always rings true for me as a means to ensure disclosure is to those that I trust; or would trust.
The discretionary access model in Gentoo is nice and to be expected; what I'd really like is a way to have my groups integrate from whichever directory service I'm using to meet the DAC mappings required on the local machine so I can enable RBAC or some other Lattice based control with local admins and limit their functions to thier jobs in an EASY fashon.
Regards,
--
Hazen Valliant-Saunders
Rooted/compromised Gentoo, seeking advice
