Security Changes For Fedora 9
Greg Metcalfe
metcalfegreg at qwest.net
Mon Jan 14 20:57:45 UTC 2008
On Monday 14 January 2008 11:16:10 am Eric Rannaud wrote:
> On Jan 10, 2008 10:26 PM, Ville Skyttä <ville.skytta at iki.fi> wrote:
> > On Saturday 05 January 2008, Kevin Fenzi wrote:
> > > I find root ssh login handy for a number of reasons:
> >
> > [...]
> >
> > > - It's nice to be able to do for automated tasks (like say installing a
> > > single new package on 20 machines without having to login and sudo on
> > > each).
> >
> > "ssh -t $host sudo yum install $package" works for me...
>
> What about (supposing I know the password of non-root user 'foo', and
> assuming that 'foo' can sudo yum):
>
> [hacker at tooeasy]$ rpm -q --scripts hacker_pkg.rpm
> postinstall scriptlet (using /bin/sh):
> rm -rf /
> exit 0
> [hacker at tooeasy]$ scp -p hackers_pkg.rpm foo at host:
> [hacker at tooeasy]$ ssh -t foo at host sudo yum localinstall --nogpgcheck
> ./hackers_pkg.rpm
>
>
> Am I wrong in assuming that yum is not necessarily a safe command to
> be used with sudo? Or more exactly, that there is no point in blocking
> root ssh logins if you're going to let a user that can login remotely
> use sudo on yum?
>
> Thanks.
>
Scary. At first glance it looks like a successful attack. But that wouldn't
really be unusual.
If your authentication model is based upon passwords, and passwords escape,
security is largely out the window. Using a wheel group, etc., can make
things tougher, but once you have a bad guy on the system, escalation of
privilege attacks are a probability, not a possibility. And they're usually
an order of magnitude (at least) easier. Authorization seldom gets the
attention that authentication does.
That's one reason (but not the major one) that I was asking about whether
anyone was thinking about mounting /home noexec. It at least adds an extra
authorization layer (though you still have to pay attention to authorization,
to prevent attacks in the same vein as the one you've described), in making
it harder to do things such as launching a dead-simple (`$0 & $0 &`) forkbomb
attack at a critical moment (which can be devastating, depending upon how you
have /etc/security/limits.conf set up).
The up side is that everyone should be on shadowed passwords, and random bad
guys with a user account can't run cracking software against /etc/passwd. The
downside is that if you have an undetected bad guy on the system, you will
probably lose, in the end. If your attack fails, another will be found. If
it's an order of magnitude easier for the bad guy, it's an order of magnitude
worse for the admin. If you were 100% confident (hubris) of protecting the
sytem before, you should now be 10% confident.
Assuming you're going to allow multiple users:
If you're going to base everything around passwords, at least read man(1)
chage, beware of shoulder-surfing, etc. If you're doing keys, protect your
~/.ssh. If you're doing two-factor, check out your vendor--some fingerprint
scanners have been trivially defeated in the past, etc.
If thou should lose the Mighty Authentication Battle, thou whilst surely find
thyself Groveling Amongst Backups.
> --
> Fedora-security-list mailing list
> Fedora-security-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-security-list
More information about the security
mailing list