bdubbs at swbell.net
Fri Apr 7 09:38:09 PDT 2006
> On Fri, Apr 07, 2006 at 06:51:44AM -0500, Randy McMurchy wrote:
>> Anything more should be offered up by Archaic, as he is the resident
>> security pundit, and if I recall correctly, is employed in a capacity
>> of overseeing connectivity and mail issues for an ISP.
> LOL. I don't really see how my job relates, but here goes! :) Unix uses
> user/group/world file-based permissions. While certainly spartan, it
> works and it is safe.  PPP has historically used cleartext passwords
> for as long as I can remember. I don't personally have a problem with it
> (though linking PPP to libcrypt and hashing sure would be a nice touch).
>>From my experience, ADSL is not persistant. My company serves DSL via 3
> different phone companies. One of those three has a subset of its
> customers doing something a bit different in that they are MAC
> authenticated. I don't know the trends, but from my experience, this is
> the exception, not the rule, and isn't changing anytime soon. So the
> problem becomes that if the password isn't stored anywhere, and you are
> not at a local keyboard, you're hosed if/when the connection drops
> because of the inability for PPP to re-auth. If PPP were to cache the
> PW, you're still in the same boat WRT cleartext passwords because the
> password would be readable in memory.
>  By safe, I mean exploiting of the user/group/world feature mechanism
> itself is not known (at least by me) to work. This doesn't mean someone
> can't pop a livecd in and effectively bypass all security models in use.
> Physical security is a different beast. Mobile laptops (i.e. laptops
> that you do actually take places) can avoid the password because there
> is a strong likelihood that it isn't meant to be run unattended like a
> server or desktop left on at home, but that should be an exercise left
> to the reader. The book can teach a few safe ideas, but can't create a
> product safer than the admin running it.
This falls in the same category of creating a web server certificate
without a password/passphrase. You have to do it so you can (re)boot
remotely. It is only protected by ownership/permissions.
More information about the blfs-dev