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
