Re: Secure 2.4.x kernel - readonly
* 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, then /home. | | /etc is written into by the kernel ( for mounts/unmounts ) ln -s /proc/mounts /etc/mtab | /proc if you use it is writable /proc is a kernel interface. It is not a real file system. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mounting /tmp noexec (was: Campus Computers)
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 binary, /lib/ld-linux.so.2 /tmp/r00tk1t. It's a bit like non-executable stacks; right now it will probably break a lot of existing exploits, but for the most part only fairly trivial modifications are needed to make them work again. So it doesn't really buy you any extra security. p. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sending password in the command line
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 program checks the password in a internal database, and enable packets from the given IP to the 0/0 world. It also logs user/ip/date. if the user does: $ myprogram disable username password IP it disables the ipchains rules that were enabled before. The program seems to be working well. Now, here is my question: - everybody can capture the passwords with a ps aux command, ok? - what about doing this to prevent simple ps aux sniff $ PASS=password myprogram enable username IP then myprogram will read the PASS from the environment. is there anyway a regular user could capture passwords? Thanks in advance, Pedro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sending password in the command line
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 enable $user $ip; rm -f $tmp`;
will this be safe now?
why don't you just do
#!/usr/bin/perl
print('enter pass: ');
$tmp = ;
system('myprogram enable $user $tmp $ip');
david flatz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sending password in the command line
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 PASS $password; close PASS; would be better... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sending password in the command line
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 mail preferred. finger [EMAIL PROTECTED] for my GnuPG/PGP key.
Save the whales. Collect the whole set.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Secure 2.4.x kernel
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 than its ammunition etc. I think THIS is something we need to see in the computer break-in laws as well: the owner of an exceedingly insecure system being used as a launchpad for further attacks should be punished as well. In the US the person who owns the gun could be punished (small penatly), only if: The gun was illegal or not registered. The penalty is usually a fine, not more than $1000.00. So its conceivable that someone could steal a firearm from your home, which wasn't legal in the first place, then commit a crime with that firearm and all that you would be charged is the fine for not registering the gun. If it was registered, its not a crime, regardless of how you store the gun or where you keep it. In the US, the home is a private and protected sancuary. I do not know why I replied to this particular message... probably because most people whose systems are very insecure are in some aspects dumb: either because they are too lazy or they simply lack the knowledge to keep it secure (and are too lazy to obtain the knowledge). I would call that dumbness. Some do not even have the slightest idea of what can be done with their computer which is sitting 24/7 on a DSL line - that is most unfortunate. Ever heard the phrase: There is nothing valuable on my computer - why would anyone break into it? Who would educate them..? Here is where you and I have a problem. Calling a person a dumbass because he or she doesn't know about computer security is basically avoiding the simple fact that not everyone knows everything, or better, not everyone *understands* computers as much as the people that bestow the knowledge. Unlike some Linux people, I don't have a problem with a person not knowing how Linux works, even at the security level. Does it bother me that people use Linux and don't know how to harden it up and make it secure, sure, I wish everyone knew about security and how to use an operating system like Linux/Unix. It would make all of our lives a little easier considering the amount of spoofing that goes on. soapbox 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 (in general) its amazing the amount of venom these Linux Pundits have towards people that are newbies. People forget that we were all newbies at one point. Just because you were using Linux in 1994 doesn't mean you weren't a newbie in 1993, catch my drift? I think its kind of sad when I visit #linux and someone drops in and says: Hey, can someone help me, I can't figure out how to shut off telnetd. The respones range from, hey, go to #LinuxHelp you newbie troll to hey, MS troll go use Micro$oft and stop bothering us Or and I love this one: RTFM... there is plenty of documentation. Really sad. Anyway, I think if people helped more dumbass people along with the security issues and general hardening of Linux up, things would get better. But I don't have much confidence that this community will take a step down from the attitude and try and remmeber that this is JUST an OS and not a friggin' elite club. People seem to want to keep Linux this little OS that could, but its so far past that now and people can't let go... In a related note, I got banned from #linux because I asked what people thought about Red Hat RPM vs. apt-get. Someone called me a troll and banned me... My reason for asking was simple: I was trying to convince someone to move all of their 32 boxes over to Debian and needed some other interesting opinions (ammunition) about apt-get vs. rpm (My reasoning was security updates are easier etc. etc.)... Getting kicked and banned made me realize that that most people (at least in that channel) aren't really interested in Linux but are interested in flexing their dick and proving to everyone about how much more knowledgable they are about a topic sigh. I guess its a form of geek revenge. /soapbox -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.310 / Virus Database: 171 - Release Date: 12/19/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system
Re: sending password in the command line
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,$tmp);
print PASS $password;
fclose PASS;
`cat $tmp | myprogram enable $user $ip; rm -f $tmp`;
will this be safe now?
why don't you just do
#!/usr/bin/perl
print('enter pass: ');
$tmp = ;
system('myprogram enable $user $tmp $ip');
david flatz
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.
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;
--
Benjamin Smith [EMAIL PROTECTED], [EMAIL PROTECTED]
msg04955/pgp0.pgp
Description: PGP signature
Re: sending password in the command line
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 best would be to add this lines to myprogram if its written in perl.
David Flatz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sending password in the command line
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. When all your wishes are granted, many of your dreams will be destroyed. -- Marilyn Manson msg04960/pgp0.pgp Description: PGP signature
RE: Secure 2.4.x kernel
-Original Message- From: Gary MacDougall soapbox 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 (in general) its amazing the amount of venom these Linux Pundits have towards people that are newbies. One of the reasons that I prefer Debian-security and Debian-user, and maybe the rest of the Debian lists too, is their generally very high signal to noise ratio. For all its faults, slashdot also demonstrates the benefits of moderation. interesting opinions (ammunition) about apt-get vs. rpm (My reasoning was security updates are easier etc. etc.)... My personal fuel for that fire is that there are no dependency problems with apt. Yes, it's an oversimplification, however I feel that once someone accustomed to needing several iterations with RPM's gets a taste of the just do it apt process, they won't notice the rare instance when there is a conflict. My hat's off to the Debian maintainers. I deeply respect their work. I guess its a form of geek revenge. Naa, it's simian posturing. It happens with humans everywhere. I enjoyed watching it in Good Will Hunting, and two days ago rented Finding Forrester (same movie, different actors), and sure enough lots of simian posturing. You dare to challenge me in MY classroom? etc. The problem is cultural and social. We've moved away from the teaching traditions that channeled such territoriality and aggression in constructive ways. Hormone-addled male teens no longer get whupped into shape when they really need it. I can suggest the writings of Jeff Cooper for a better exploration of the kinds of attitudes and processes that are now missing, and R.A.Heinlein for lots of fictional explorations of the issue. There's some really nasty little flame freaks out there who simply do not understand the repercussions of their words, and how they hurt people. They've never been taught how to argue with their (recently evolved) brains. Curt- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
/etc/passwd ?
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
Re: /etc/passwd ?
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 wrote: 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 Petre L. Daniel,System Administrator Canad Systems Pitesti Romania, http://www.cyber.ro, email:[EMAIL PROTECTED] Tel:+4048220044, +4048206200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/passwd ?
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 telnet/ssh account for the games accound is a good idea ;) 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.. 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secure 2.4.x kernel - readonly
* 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, then /home. | | /etc is written into by the kernel ( for mounts/unmounts ) ln -s /proc/mounts /etc/mtab | /proc if you use it is writable /proc is a kernel interface. It is not a real file system. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: mounting /tmp noexec (was: Campus Computers)
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 binary, /lib/ld-linux.so.2 /tmp/r00tk1t. It's a bit like non-executable stacks; right now it will probably break a lot of existing exploits, but for the most part only fairly trivial modifications are needed to make them work again. So it doesn't really buy you any extra security. p.
Re: sending password in the command line
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 stdin like mysql -p David Flatz
Re: sending password in the command line
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 auxe try getting the password via stdin like mysql -p 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 enable $user $ip; rm -f $tmp`; will this be safe now? Thanks, Pedro
Re: sending password in the command line
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 enable $user $ip; rm -f $tmp`;
will this be safe now?
why don't you just do
#!/usr/bin/perl
print('enter pass: ');
$tmp = ;
system('myprogram enable $user $tmp $ip');
david flatz
Re: sending password in the command line
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 PASS $password; close PASS; would be better...
Re: sending password in the command line
-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 net-device port the port your prog uses Weissi -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8K0ze3lkVkvL9FpcRAlodAKDPPI1rxQOJ3vZc05Satnuc8JXgdgCfbHzh bNDaFtN/y9WoMND4NvHeQKU= =cCeQ -END PGP SIGNATURE-
Re: sending password in the command line
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 mail preferred. finger [EMAIL PROTECTED] for my GnuPG/PGP key.
Save the whales. Collect the whole set.
RE: Secure 2.4.x kernel
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 than its ammunition etc. I think THIS is something we need to see in the computer break-in laws as well: the owner of an exceedingly insecure system being used as a launchpad for further attacks should be punished as well. In the US the person who owns the gun could be punished (small penatly), only if: The gun was illegal or not registered. The penalty is usually a fine, not more than $1000.00. So its conceivable that someone could steal a firearm from your home, which wasn't legal in the first place, then commit a crime with that firearm and all that you would be charged is the fine for not registering the gun. If it was registered, its not a crime, regardless of how you store the gun or where you keep it. In the US, the home is a private and protected sancuary. I do not know why I replied to this particular message... probably because most people whose systems are very insecure are in some aspects dumb: either because they are too lazy or they simply lack the knowledge to keep it secure (and are too lazy to obtain the knowledge). I would call that dumbness. Some do not even have the slightest idea of what can be done with their computer which is sitting 24/7 on a DSL line - that is most unfortunate. Ever heard the phrase: There is nothing valuable on my computer - why would anyone break into it? Who would educate them..? Here is where you and I have a problem. Calling a person a dumbass because he or she doesn't know about computer security is basically avoiding the simple fact that not everyone knows everything, or better, not everyone *understands* computers as much as the people that bestow the knowledge. Unlike some Linux people, I don't have a problem with a person not knowing how Linux works, even at the security level. Does it bother me that people use Linux and don't know how to harden it up and make it secure, sure, I wish everyone knew about security and how to use an operating system like Linux/Unix. It would make all of our lives a little easier considering the amount of spoofing that goes on. soapbox 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 (in general) its amazing the amount of venom these Linux Pundits have towards people that are newbies. People forget that we were all newbies at one point. Just because you were using Linux in 1994 doesn't mean you weren't a newbie in 1993, catch my drift? I think its kind of sad when I visit #linux and someone drops in and says: Hey, can someone help me, I can't figure out how to shut off telnetd. The respones range from, hey, go to #LinuxHelp you newbie troll to hey, MS troll go use Micro$oft and stop bothering us Or and I love this one: RTFM... there is plenty of documentation. Really sad. Anyway, I think if people helped more dumbass people along with the security issues and general hardening of Linux up, things would get better. But I don't have much confidence that this community will take a step down from the attitude and try and remmeber that this is JUST an OS and not a friggin' elite club. People seem to want to keep Linux this little OS that could, but its so far past that now and people can't let go... In a related note, I got banned from #linux because I asked what people thought about Red Hat RPM vs. apt-get. Someone called me a troll and banned me... My reason for asking was simple: I was trying to convince someone to move all of their 32 boxes over to Debian and needed some other interesting opinions (ammunition) about apt-get vs. rpm (My reasoning was security updates are easier etc. etc.)... Getting kicked and banned made me realize that that most people (at least in that channel) aren't really interested in Linux but are interested in flexing their dick and proving to everyone about how much more knowledgable they are about a topic sigh. I guess its a form of geek revenge. /soapbox -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.310 / Virus Database: 171 - Release Date: 12/19/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system
Re: sending password in the command line
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,$tmp);
print PASS $password;
fclose PASS;
`cat $tmp | myprogram enable $user $ip; rm -f $tmp`;
will this be safe now?
why don't you just do
#!/usr/bin/perl
print('enter pass: ');
$tmp = ;
system('myprogram enable $user $tmp $ip');
david flatz
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.
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;
--
Benjamin Smith [EMAIL PROTECTED], [EMAIL PROTECTED]
pgpNjYxGOIMor.pgp
Description: PGP signature
Re: sending password in the command line
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 best would be to add this lines to myprogram if its written in perl.
David Flatz
Re: sending password in the command line
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 might not be the solution you are looking for. -xbud On Thursday 27 December 2001 09:27 am, Pedro Zorzenon Neto wrote: 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 program checks the password in a internal database, and enable packets from the given IP to the 0/0 world. It also logs user/ip/date. if the user does: $ myprogram disable username password IP it disables the ipchains rules that were enabled before. The program seems to be working well. Now, here is my question: - everybody can capture the passwords with a ps aux command, ok? - what about doing this to prevent simple ps aux sniff $ PASS=password myprogram enable username IP then myprogram will read the PASS from the environment. is there anyway a regular user could capture passwords? Thanks in advance, Pedro
Re: sending password in the command line
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 program? Why don't you program just ask the password? Merlin -- A paixão dos olhos das crianças é toda a magia que o mundo precisa! Alguem disse, talvez Merlin: Camelot vai renascer... Brevemente... Online!!
Re: sending password in the command line
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 password. Why is all that for ? Isn't you who's writing the program? Why don't you program just ask the password? No, I'm not. If the password is passed over stdin, the program would need to ask for the password. I think the whole idea is to have one program to either enable or disable the access for that ip but only if the password is given, and then to automate this in a script by coding the password into the script. Merlin -- A paixão dos olhos das crianças é toda a magia que o mundo precisa! Alguem disse, talvez Merlin: Camelot vai renascer... Brevemente... Online!! -- Benjamin Smith [EMAIL PROTECTED], [EMAIL PROTECTED] pgpCkuVXH4inx.pgp Description: PGP signature
Re: sending password in the command line
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. When all your wishes are granted, many of your dreams will be destroyed. -- Marilyn Manson pgpovgJjUksTn.pgp Description: PGP signature
Re: sending password in the command line
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 password. Why is all that for ? Isn't you who's writing the program? Why don't you program just ask the password? It will be used mostly non-interactive. The user can run it inside a cronjob or a www/cgiscript. I can also write a user-interface for the program which asks the password. But the low-level interface will not be interactive.
RE: Secure 2.4.x kernel
-Original Message- From: Gary MacDougall soapbox 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 (in general) its amazing the amount of venom these Linux Pundits have towards people that are newbies. One of the reasons that I prefer Debian-security and Debian-user, and maybe the rest of the Debian lists too, is their generally very high signal to noise ratio. For all its faults, slashdot also demonstrates the benefits of moderation. interesting opinions (ammunition) about apt-get vs. rpm (My reasoning was security updates are easier etc. etc.)... My personal fuel for that fire is that there are no dependency problems with apt. Yes, it's an oversimplification, however I feel that once someone accustomed to needing several iterations with RPM's gets a taste of the just do it apt process, they won't notice the rare instance when there is a conflict. My hat's off to the Debian maintainers. I deeply respect their work. I guess its a form of geek revenge. Naa, it's simian posturing. It happens with humans everywhere. I enjoyed watching it in Good Will Hunting, and two days ago rented Finding Forrester (same movie, different actors), and sure enough lots of simian posturing. You dare to challenge me in MY classroom? etc. The problem is cultural and social. We've moved away from the teaching traditions that channeled such territoriality and aggression in constructive ways. Hormone-addled male teens no longer get whupped into shape when they really need it. I can suggest the writings of Jeff Cooper for a better exploration of the kinds of attitudes and processes that are now missing, and R.A.Heinlein for lots of fictional explorations of the issue. There's some really nasty little flame freaks out there who simply do not understand the repercussions of their words, and how they hurt people. They've never been taught how to argue with their (recently evolved) brains. Curt-
/etc/passwd ?
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
Re: /etc/passwd ?
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 wrote: 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 Petre L. Daniel,System Administrator Canad Systems Pitesti Romania, http://www.cyber.ro, email:[EMAIL PROTECTED] Tel:+4048220044, +4048206200
Re: /etc/passwd ?
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 telnet/ssh account for the games accound is a good idea ;) 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.. 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.
Re: mounting /tmp noexec (was: Campus Computers)
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 binhtml mail src adebian lib package-sync.log tmp If you remove the execute bit from ld.so to avoid this, you in turn break execution of all deymaically linked libc6 programs. So sure, noexec does raise the bar tiny little bit, just because an attacker needs to remember to try this trick, and needs to be able to do so in their exploit. Anyway, I would like to make debconf (er, really apt-utils) use a different temporary directory, but I have not been able to come up with better one so far. -- see shy jo
