Merlin writes:
> On Thursday 27 December 2001 16:46, Benjamin Smith wrote:
> >
> > Because that doesn't solve the original problem of the password being
> > visible on the command line. The environment and the stdin were two
> > suggested ways of passing the password.
> >
>
ps -e shows the env
Ian wrote:
> why is this? Surely it is better security to do so?
[EMAIL PROTECTED]:~>ls -l ./ls
-rw---1 joey joey43916 Dec 26 22:46 ./ls
[EMAIL PROTECTED]:~>/lib/ld-2.2.4.so ./ls
CVS aalib.nohack.diff doc lsscreenshot.png
GNUstep binhtm
just run "info false"
[...]
This version of `false' is implemented as a C program, and is thus
more secure and faster than a shell script implementation, and may
safely be used as a dummy shell for the purpose of disabling accounts.
so, a "chsh -s /bin/false games" for disabling a telne
most of them are relics of software that you probably dont need,but be
carefully what account you erase.
better comment them out.you can put a /etc/NOSHELL instead of /bin/sh or
even /bin/false and they won't be able to login into the machine no more..
At 06:24 PM 12/27/01 -0600, Daniel Rychlik
I was wandering if I edited my /etc/passwd file and
replaced all the /bin/sh to /bin/false , will that break anything?
What Im seeing is accounts like lp, games, uucp,
proxy, postgres, and a slew of others that I dont use.
Thanks in advance Debian Guruz!
Daniel
> -Original Message-
> From: Gary MacDougall
>
> I'm gong to get flamed like hell for this, but I think the general
> attitude of people that consider themselves "Linux Security
> Guru's" sucks!
> If you've ever visited #linux on IRC or talked with people in
> a chat room
> about Linux
Ian wrote:
> why is this? Surely it is better security to do so?
joey@silk:~>ls -l ./ls
-rw---1 joey joey43916 Dec 26 22:46 ./ls
joey@silk:~>/lib/ld-2.2.4.so ./ls
CVS aalib.nohack.diff doc lsscreenshot.png
GNUstep binhtml mail
just run "info false"
[...]
This version of `false' is implemented as a C program, and is thus
more secure and faster than a shell script implementation, and may
safely be used as a dummy shell for the purpose of disabling accounts.
so, a "chsh -s /bin/false games" for disabling a teln
most of them are relics of software that you probably dont need,but be
carefully what account you erase.
better comment them out.you can put a /etc/NOSHELL instead of /bin/sh or
even /bin/false and they won't be able to login into the machine no more..
At 06:24 PM 12/27/01 -0600, Daniel Rychlik
I was wandering if I edited my /etc/passwd file and
replaced all the /bin/sh to /bin/false , will that break anything?
What Im seeing is accounts like lp, games, uucp,
proxy, postgres, and a slew of others that I dont use.
Thanks in advance Debian Guruz!
Daniel
> -Original Message-
> From: Gary MacDougall
>
> I'm gong to get flamed like hell for this, but I think the general
> attitude of people that consider themselves "Linux Security
> Guru's" sucks!
> If you've ever visited #linux on IRC or talked with people in
> a chat room
> about Linux
On Thu, Dec 27, 2001 at 05:16:16PM +, Merlin wrote:
> On Thursday 27 December 2001 16:46, Benjamin Smith wrote:
> >
> > Because that doesn't solve the original problem of the password being
> > visible on the command line. The environment and the stdin were two
> > suggested ways of passing the
Hi,
There's a secure-coding (or somesuch) mailinglist over at securityfocus,
that might be better suited to these kinds of discussions..
Greets,
Robert
--
Linux Generation
encrypted mail preferred. finger [EMAIL PROTECTED] for my GnuPG/PGP key.
On Thu, Dec 27, 2001 at 05:16:16PM +, Merlin wrote:
> On Thursday 27 December 2001 16:46, Benjamin Smith wrote:
> >
> > Because that doesn't solve the original problem of the password being
> > visible on the command line. The environment and the stdin were two
> > suggested ways of passing the
On Thursday 27 December 2001 16:46, Benjamin Smith wrote:
>
> Because that doesn't solve the original problem of the password being
> visible on the command line. The environment and the stdin were two
> suggested ways of passing the password.
>
Why is all that for ?
Isn't you who's writing the pr
This will not work I believe ps aux will show the environment variable's
value instead of the variable. Which in your case would be the password,
rendering your idea bad! =/
I would chroot the users' environments (jail them) so that they can only see
their own processes... of course this mig
Benjamin Smith said:
> > #!/usr/bin/perl
> > print('enter pass: ');
> > $tmp = <>;
> > system('myprogram enable $user $tmp $ip');
>
> I think the first bit of code would work but why not use pipe opens in
> perl? ie.
>
> open(PASS, "|myprogram enable $user $ip);
> write PASS "PASSWORD";
>
the b
On Thu, Dec 27, 2001 at 05:22:03PM +0100, David Flatz wrote:
> Pedro Zorzenon Neto said:
> > Thanks for you sugestion David,
> >
> > As it is a Perl script that will call the program, I'll do in the Perl
> > code something like this:
> >
> > $tmp=`umask 177; tempfile`;
> > fopen (PASS,">$
> Now, I do not know about American law, but at least in Finland the
>guy whose gun (assault rifles are illegal anyway unless they are
>rendered non-automatic) was stolen, is likely to get punished as well!
>It depends on how the gun was stored: it needs to be locked away in a
>different location
Quoting David Flatz ([EMAIL PROTECTED]):
> #!/usr/bin/perl
> print('enter pass: ');
> $tmp = <>;
> system('myprogram enable $user $tmp $ip');
Because then you would still pass the password on the commandline.
Greets,
Robert
--
Linux Generation
encrypted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
If you send your password through a network the sniffer could also sniff the
TCP-stream, try ngrep -d port
Weissi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8K0ze3lkVkvL9Fp
On Thu, Dec 27, 2001 at 02:11:42PM -0200, Pedro Zorzenon Neto wrote:
>
> $tmp=`umask 177; tempfile`;
> fopen (PASS,">$tmp");
> print PASS $password;
> fclose PASS;
> `cat $tmp | myprogram enable $user $ip; rm -f $tmp`;
sorry...
open (PASS,"| myprogram enable $user $ip");
print PA
Pedro Zorzenon Neto said:
> Thanks for you sugestion David,
>
> As it is a Perl script that will call the program, I'll do in the Perl
> code something like this:
>
> $tmp=`umask 177; tempfile`;
> fopen (PASS,">$tmp");
> print PASS $password;
> fclose PASS;
> `cat $tmp | myprogram e
On Thu, Dec 27, 2001 at 04:46:45PM +0100, David Flatz wrote:
> Pedro Zorzenon Neto said:
> > $ PASS="password" myprogram enable username IP
> >
> > then "myprogram" will read the PASS from the environment.
> > is there anyway a regular user could capture passwords?
>
> yes it is "ps
Pedro Zorzenon Neto said:
> $ PASS="password" myprogram enable username IP
>
> then "myprogram" will read the PASS from the environment.
> is there anyway a regular user could capture passwords?
yes it is "ps auxe"
try getting the password via like "mysql -p"
David Flatz
On Thu, Dec 27, 2001 at 05:16:16PM +, Merlin wrote:
> On Thursday 27 December 2001 16:46, Benjamin Smith wrote:
> >
> > Because that doesn't solve the original problem of the password being
> > visible on the command line. The environment and the stdin were two
> > suggested ways of passing th
Hi,
There's a secure-coding (or somesuch) mailinglist over at securityfocus,
that might be better suited to these kinds of discussions..
Greets,
Robert
--
Linux Generation
encrypted mail preferred. finger [EMAIL PROTECTED] for my GnuPG/PGP key.
Hi Friends,
I am developing a software to provide access control to users of a
network.
The gateway has ipchains rules to DENY packets from all 192.168.0.0/16
hosts to the 0.0.0.0/0 world.
If the user (a regular user, not root) does:
$ myprogram enable username password IP
the pr
On Thu, Dec 27, 2001 at 05:16:16PM +, Merlin wrote:
> On Thursday 27 December 2001 16:46, Benjamin Smith wrote:
> >
> > Because that doesn't solve the original problem of the password being
> > visible on the command line. The environment and the stdin were two
> > suggested ways of passing th
On Thursday 27 December 2001 16:46, Benjamin Smith wrote:
>
> Because that doesn't solve the original problem of the password being
> visible on the command line. The environment and the stdin were two
> suggested ways of passing the password.
>
Why is all that for ?
Isn't you who's writing the p
This will not work I believe ps aux will show the environment variable's
value instead of the variable. Which in your case would be the password,
rendering your idea bad! =/
I would chroot the users' environments (jail them) so that they can only see
their own processes... of course this mi
Benjamin Smith said:
> > #!/usr/bin/perl
> > print('enter pass: ');
> > $tmp = <>;
> > system('myprogram enable $user $tmp $ip');
>
> I think the first bit of code would work but why not use pipe opens in
> perl? ie.
>
> open(PASS, "|myprogram enable $user $ip);
> write PASS "PASSWORD";
>
the
On Thu, Dec 27, 2001 at 05:22:03PM +0100, David Flatz wrote:
> Pedro Zorzenon Neto said:
> > Thanks for you sugestion David,
> >
> > As it is a Perl script that will call the program, I'll do in the Perl
> > code something like this:
> >
> > $tmp=`umask 177; tempfile`;
> > fopen (PASS,">
> Now, I do not know about American law, but at least in Finland the
>guy whose gun (assault rifles are illegal anyway unless they are
>rendered non-automatic) was stolen, is likely to get punished as well!
>It depends on how the gun was stored: it needs to be locked away in a
>different locatio
Quoting David Flatz ([EMAIL PROTECTED]):
> #!/usr/bin/perl
> print('enter pass: ');
> $tmp = <>;
> system('myprogram enable $user $tmp $ip');
Because then you would still pass the password on the commandline.
Greets,
Robert
--
Linux Generation
encrypted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
If you send your password through a network the sniffer could also sniff the
TCP-stream, try ngrep -d port
Weissi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8K0ze3lkVkvL9F
On Thu, Dec 27, 2001 at 02:11:42PM -0200, Pedro Zorzenon Neto wrote:
>
> $tmp=`umask 177; tempfile`;
> fopen (PASS,">$tmp");
> print PASS $password;
> fclose PASS;
> `cat $tmp | myprogram enable $user $ip; rm -f $tmp`;
sorry...
open (PASS,"| myprogram enable $user $ip");
print P
Pedro Zorzenon Neto said:
> Thanks for you sugestion David,
>
> As it is a Perl script that will call the program, I'll do in the Perl
> code something like this:
>
> $tmp=`umask 177; tempfile`;
> fopen (PASS,">$tmp");
> print PASS $password;
> fclose PASS;
> `cat $tmp | myprogram
On Thu, Dec 27, 2001 at 04:46:45PM +0100, David Flatz wrote:
> Pedro Zorzenon Neto said:
> > $ PASS="password" myprogram enable username IP
> >
> > then "myprogram" will read the PASS from the environment.
> > is there anyway a regular user could capture passwords?
>
> yes it is "p
Pedro Zorzenon Neto said:
> $ PASS="password" myprogram enable username IP
>
> then "myprogram" will read the PASS from the environment.
> is there anyway a regular user could capture passwords?
yes it is "ps auxe"
try getting the password via like "mysql -p"
David Flatz
--
T
Hi Friends,
I am developing a software to provide access control to users of a
network.
The gateway has ipchains rules to DENY packets from all 192.168.0.0/16
hosts to the 0.0.0.0/0 world.
If the user (a regular user, not root) does:
$ myprogram enable username password IP
the p
> Just because people are "dumb" or not as fortunate as other more
> "privy" people, doesn't mean that the law should bypass the
> "unfortunate". The law (at least in the US) were specifically
> created to protect people in such circumstances. Why should
> computer law be any different?
Actual
In message <[EMAIL PROTECTED]>, Ian writes:
>so surely, if nothing needs to be executed, it is better to mount
>noexec?
The thing about noexec is that you can almost always circumvent it. If you
have a shell script in /tmp that you want to execute, you can use
"sh /tmp/r00tk1t". If you have a b
> Just because people are "dumb" or not as fortunate as other more
> "privy" people, doesn't mean that the law should bypass the
> "unfortunate". The law (at least in the US) were specifically
> created to protect people in such circumstances. Why should
> computer law be any different?
Actua
* Alvin Oga
| On Mon, 24 Dec 2001, Anthony DeRobertis wrote:
|
| > > making the disks readonly is not trivial ...
| > > lots of work to make it readonly.. a fun project ...
| >
| > Not really. Nothing should write anywhere except /var and /tmp
| > (did I miss any). Also, if you have users, th
In message <[EMAIL PROTECTED]>, Ian writes:
>so surely, if nothing needs to be executed, it is better to mount
>noexec?
The thing about noexec is that you can almost always circumvent it. If you
have a shell script in /tmp that you want to execute, you can use
"sh /tmp/r00tk1t". If you have a
* Alvin Oga
| On Mon, 24 Dec 2001, Anthony DeRobertis wrote:
|
| > > making the disks readonly is not trivial ...
| > > lots of work to make it readonly.. a fun project ...
| >
| > Not really. Nothing should write anywhere except /var and /tmp
| > (did I miss any). Also, if you have users, t
47 matches
Mail list logo
