Date: Tue, 21 Dec 2004 15:57:06 +0100 From: Gerhard Schmidt <estartu@augusta.de> To: Bill Vermillion <bv@wjv.com> Subject: Re: Strange command histories in hacked shell history Message-ID: <20041221145706.GA5694@augusta.de> Resent-Message-ID: <200412211510.iBLFAknQ011642@etustar.ze.tum.de> In-Reply-To: <20041220171836.GC81898@wjv.com> References: <20041217120138.7A89116A4D2@hub.freebsd.org> <20041217145315.GB68582@wjv.com> <20041220095628.GA98945@augusta.de> <20041220171836.GC81898@wjv.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Mon, Dec 20, 2004 at 12:18:36PM -0500, Bill Vermillion wrote: > While normally not able to pour water out of a boot with > instructions on the heel, on Mon, Dec 20, 2004 at 10:56 > our dear friend Gerhard Schmidt uttered this load of codswallop: Offending other people isn`t funny and totaly displaced on this List. > > On Fri, Dec 17, 2004 at 09:53:15AM -0500, Bill Vermillion wrote: > > [much deleted - wjv] > > > > > Can anyone explain why su does not use the UID from the login > > > instead of the EUID ? It strikes me as a security hole, but I'm no > > > security expert so explanations either way would be welcomed. > > > I'm not a security expert, but if someone has the > > Username/Password for an Account that can su to root. Where is > > the point of disallowing him to su to this user and than to su. > > You can?t prevent him form directly logging in as this User > > an than use su. Therefore there is no gain in security just a > > drawback in usefulness. I use this often to get a rootshell on > > an Xsession from an user who can't su to root. > > You can limit the access for the person who has wheel/su > privledges by running sshd and then permitting connections only > from certain IPs or IP blocks. So another person is severely > restricited from logging in as this user even if they have cracker > that persons password. But once the craccker is in the system they > can attempt breaking the password on a local basis, and the attack > the root system. With reasonable passwords for accounts able to su to root you should be able to detect any local cracking activity bevor they are able to crack the password. > I think the comment one other person made about limiting the su > stack to 1, so that you can not su to an account and then su to > another account is a good approach. OK than the create uses login to change the user and than su to root. where is the improvment in security. > Considering the HUGE abount of attempted SSH logins I see on my > servers from all over the world, with most coming from Korea, > China, and lately Brazil, to add to those from Germany and Russia > [just some I recall from the whois queries] andthing we can do > to improve the security is a step forward. me too. But im not worried by them. Im more worried by the connects that don't try to login. > In server environments security far outweighs all other > considerations IMO. Than you should consider pulling the main power and network plugs. This will impove system securirty to new dimensions. There should be a balance between security and comfort. I see your point, but FreeBSD isn't a server only operating system. I use FreeBSD as desktop OS on all our Workstations and Servers. Maybe this should by tuneable. Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | Privat: estartu@augusta.de | auf Anfrage/ Germany | | on request [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: xx735o4ypFJdnKnLcUr1fGPZujVFmv67 iQCVAwUBQcg5wQzx22nOTJQRAQEsfAQAgc+flgh4WFhfQNQzbRmtWvD+4/2UyzNI lGnAjtrnaCYsjBL+UyKwGUksOQIfirsagPat1bgiPbTQoGcSqdsQtFtEgn9IcK0C bHbOZOmSjqfcPcznrWbrhV+z5vxldwOkLs61HV/S18T+LcG+12UB7BSROZ8Cm7N4 f3pTJ1B5hYQ= =wODc -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041221145706.GA5694>