On Sat, 13 Nov 1999, Alexander Leidinger wrote:
> On 12 Nov, Robert Watson wrote:
>
> >> >> >> (102) netchild@ttyp2 > grep cat /etc/rc.conf.local
> >> >> >> spppconfig_isp0="`cat /etc/isdn/connect.parameters`"
> >> > ^^^
> >> > Calling programs from any of the rc.conf files is considered evil
> >> > and it's looked down on.
> >>
> >> Itīs there to hide login/passwd information for i4b.
> >
> > But it seems like the end up as arguments to ifconfig at a later date,
> ^^ s/if/spp/
>
> > where a user can pull them out of ps, /proc, etc. The window there
> > is clearly shorter than keeping it in /etc/rc.conf, but still not
>
> It will only be in /proc (ps, etc.) at execution-/boot-time or am I
> missing something?
Yes -- the window of exposure is while a program is running that either a)
has the password as a command line argument, or b) has the variable as an
environmental variable. Opportunities for using ps to pull this
information out happen after the sppp* portion of rc.network, but begin as
early as sendmail (.forward and deferred delivery), cron (crontab), httpd
(cgi), etc. And it's important to keep in mind that every time rc.conf is
executed, it will pull in the password using the `...` clause, and store
it in the execution environment of the caller. Not the same as being in
the exposed environmental variables, but it's more exposure in the sense
that if the program coredumps (i.e., the sh running the script that
invoked /etc/rc.conf) the contents will be in the dump. Later invocations
of spppcontrol in userland will expose their arguments to the world also.
The generally preferred way to pass in passwords to a program is either to
provide the program with an argument that is the filename storing the
password, or to pass it in via stdin. E.g.,
% program -p /etc/private/my_password
% cat /etc/private/my_password | program -p -
Robert N M Watson
[EMAIL PROTECTED] http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
