--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 =20
> our dear friend Gerhard Schmidt uttered this load of codswallop:
Offending other people isn`t funny and totaly displaced on this=20
List.=20
> > On Fri, Dec 17, 2004 at 09:53:15AM -0500, Bill Vermillion wrote:
>=20
> [much deleted - wjv]
>=20
>=20
> > > 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.
>=20
> > 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.
>=20
> 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=20
crack the password. =20
> 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.=20
where is the improvment in security.=20
=20
> 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=20
that don't try to login.=20
> In server environments security far outweighs all other
> considerations IMO. =20
Than you should consider pulling the main power and network plugs. This=20
will impove system securirty to new dimensions.=20
There should be a balance between security and comfort. I see your point,=
=20
but FreeBSD isn't a server only operating system. I use FreeBSD as desktop=
=20
OS on all our Workstations and Servers. Maybe this should by tuneable.=20
Bye
Estartu
----------------------------------------------------------------------------
Gerhard Schmidt | Nick : estartu IRC : Estartu |
Fischbachweg 3 | | PGP Public Key
86856 Hiltenfingen | Privat: estartu@augusta.de | auf Anfrage/
Germany | | on request
--jI8keyz6grp/JLjh
Content-Type: application/pgp-signature
Content-Disposition: inline
-----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-----
--jI8keyz6grp/JLjh--