Re: [gentoo-user] Rooted/compromised Gentoo, seeking advice

[Hazen Valliant-Saunders]

On Tue, Aug 10, 2010 at 2:50 PM, Alan McKinnon <alan.mckinnon@×××××.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@g.o>
> 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@×××××.com
> >
> > >
> > > wrote:
> > > > > I actually prefer "sudo su -" -- as long as I'm giving it away!
>  :o)
> > >
> > > 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