portscans and sniffing
Hi all. I have startet a Security Company in Germany an now i have e few questions. Are ftp anonymous scans illegal? if it is, can i get an license to do penetrations test? thx for help, thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: portscans and sniffing
On Mon, Jan 21, 2002 at 10:36:18AM +0100, [EMAIL PROTECTED] wrote: Hi all. I have startet a Security Company in Germany an now i have e few questions. First try learning how to write :) Are ftp anonymous scans illegal? That depends on what country the system is located in, but generally it is considere illegal to portscan or attemt to access systems you are not authorized to access. However there is hardly any enforcement of these rules. if it is, can i get an license to do penetrations test? I suggest you only scan systems you are authorized to scan by their respective owners (your clients) and keep well away from other people's boxes. Mark Janssen Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT E-mail: mark(at)markjanssen.nl / maniac(at)maniac.nl GnuPG Key Id: 357D2178 Web: Maniac.nl Unix-God.[Net|Org] MarkJanssen.[com|net|org|nl] SyConOS.[com|nl] msg05430/pgp0.pgp Description: PGP signature
Mail server anti-virus software?
Hi. I am setting up a (updating an existing) mail server at our company and would like to get some recommendations on what anti-virus software to run on the server. Currently I'm only looking for an on-demand mail scanner. (Maybe also with some kind of HTTP proxy support too. On-access scanning would also be a nice option, if I set up a samba server later.) I've tried to check a few websites for info on the commercial products, but I find them mostly confusing. Many have like one to a billion different 'products' or 'solutions' listed and I can't find the magic word linux anywhere either... :/ Well, here's my list of questions: Are there any free or no cost solutions (for corporate use)? Should I go for McAfee, Kaspersky, H+BEDV, Trend Micro, F-Secure or something else? What are you using? What's good or bad about them/it? Is there any comparisions of the products available in the web? Also, which mailserver would you recommend? (I have to learn one anyway.) Any good resources in the web? The server is running Debian Potato 2.2 with Bunk's kernel 2.4 updates. Current kernel is 2.2.19, but I will probably update it to 2.4(.17) soon to get ext3 support. The current MTA is sendmail 8.9.3-23. (The HTTP proxy solution that the company uses, is Apache 1.3.9-14 with proxy_module and Junkbuster 2.0-7.1) Thanks in advance, -- Mikko Kilpikoski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.20.0245 +0100]: If the use of switch user has remote security implications I want to be able to understand them. The same as I want to be able to understand if leaving a root console open has remote security implications. Don't worry about local physical access. I want everyone to assume this is impossible. You have to assume this is impossible to not get sidetracked. the point is that you can't assume that. i hold network security seminars on a regular basis, and i research the facts every single time as well as possible, just to deliver the most accurate info to my students. excuse me if i can't provide you with a source (it was CERT), but my notes from the seminar that i was to hold today (it was canceled) state that 76% of all attacks are internal, and that around 40% of those are physical attacks, the remaining 60% are network attacks. okay, we are getting sidetracked, but local physical access is never impossible. and it's all too often a factor that is ignored. nevertheless, leave a root console open on a production machine really just calls for trouble. imagine you are about to head for lunch with a friend, but you decide to check something in the server room quickly. while you stare at your Annex ports or your Cisco switch, your friend idles around and notices the root console. had there not been a root console, he would have never thought of doing what he now does, but since the prompt # is so inviting, he takes all of 20 seconds to install a backdoor in the system, binding a shell to a high port, installing his RSA identity.pub in /root/.ssh, scp'ing/email'ing /etc/shadow to himself etc. no. he'd have to steal your actual tty session, and if all you are doing is surfing the web, then he can't really do that. however, which browser are you using? are you running X? why not use tty2-tty6 for a separate user login? Please don't worry about what else I could do. That's all sensible (unnecessary) advice. I want to understand this from a theoretical viewpoint. It gives me a very weird feeling in my intestines as well using su - to switch to a user account and I want to understand why. if you use the console only, and lynx or w3m to browse the web, you might be fine. if you start X as root, and run the browser as root, or if you somehow start X in general, security issues pop up everywhere. there's a reason why a server's a server and a workstation's a workstation. no, i can't give you a precise recipe or a definite this-is-how-it-is answer, simply because this is what security is all about: there is no right or wrong, there are simply gut feelings, and the good security administrators have sensible guts. it's really what makes security interesting and what keeps you young :) Can anyone provide a plausible scenario for how someone might be able to gain root level access because su - has been used to switch to a user account. Martin has already answered that your tty session would have to be stolen. How can you steal a tty session using only remote means? you'd have to be more specific as to what you are doing locally. X or not X? well, i guess that you're expecting a potential attacker not to know this. the only thing i can think of are escape sequences through /dev/tty, which cause the local shell to be trashed and possibly made to execute commands. whether you can harvest a privilege escalation from that, well, i am sure you can. i don't have a recipe off-hand. i just read ahead in the thread to see that someone else posted this already. woops. i think that you have a conceptual problem with what a server and a workstation are, and their differences, and what a superuser account is to be used for. in all but the rarest cases do production servers even have local accounts, and if, then usually without shell access. yes, i know that there are companies and institutions that provide shell access, but they usually have dedicated servers for that. i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck when I was a boy I was told that anybody could become president. now i'm
Re: Re: How do I disable (close) ports?
On Wed, Jan 16, 2002 at 12:36:21PM -0500, Noah L. Meyerhans wrote: On Wed, Jan 16, 2002 at 12:25:34PM -0500, Chris Hilts wrote: It seems to. The above ports were closed just by commenting them out of /etc/services and then rebooting. An init 1, init 3 would have worked as well. Correct me if I'm wrong here, but why would you comment things out of /etc/services? Try /etc/inetd.conf or /etc/xinetd.conf Yes, this was discussed at length when the thread was current some time ago. I am not sure why Mr. Weir just replied today. Sorry, must have got stuck in the spool;) -rob msg05433/pgp0.pgp Description: PGP signature
RE: Mail server anti-virus software?
I've tried to check a few websites for info on the commercial products, but I find them mostly confusing. Many have like one to a billion different 'products' or 'solutions' listed and I can't find the magic word linux anywhere either... :/ Well, here's my list of questions: Are there any free or no cost solutions (for corporate use)? Officially - no. I'd recommend Kaspersky or drweb32. The have close to similar functionality on the server side. Should I go for McAfee, Kaspersky, H+BEDV, Trend Micro, F-Secure or something else? What are you using? I am using kaspersky mail server antivirus - it seamlessly integrates into most of exisiting mail servers under unix (sendmail, qmail, exim, postfix). The only reason is they have offered free beta evaluation to me. What's good or bad about them/it? Nothing bad as for me :) Oh, yeah - McAfee doesn't have suitable software solution - only combined with hardware. Nothing bad but the cost... Is there any comparisions of the products available in the web? Concerning what? As for number of viruses - McAfee and Kaspersky. As for friendly user interface - I don't care. It is server solution for me, so config files are ok. :) As for size - drweb32. Also, which mailserver would you recommend? (I have to learn one anyway.) I'd recommend QMail. Why? - Read some mailing lists... And this is commonly the question of religion. Wish you good luck in this constant war! Anton. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mail server anti-virus software?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Am Montag, 21. Januar 2002 11:17 schrieb Mikko Kilpikoski: Hi. I am setting up a (updating an existing) mail server at our company and would like to get some recommendations on what anti-virus software to run on the server. Currently I'm only looking for an on-demand mail scanner. (Maybe also with some kind of HTTP proxy support too. On-access scanning would also be a nice option, if I set up a samba server later.) I got somewhat confused :-) and did not reply to the list, but I suggested a look at http://www.openantivirus.org/ Ciao, Mirko - -- Mirko Wollenberg | Systemberater Kleine Rainstrasse 28 | 22765 Hamburg GSM: +49 170/ 554 78 72 http://www.mirkow.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8S/+E0uLUIzwK8qsRAj5SAJ9vXF5Q1vO+VpjKDpxtH/1oHYqLjwCZAXnV bf59p+IYpW/5MC2KCIrWE+g= =vpwh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mail server anti-virus software?
also sprach Antropov Anton [EMAIL PROTECTED] [2002.01.21.1231 +0100]: Also, which mailserver would you recommend? (I have to learn one anyway.) I'd recommend QMail. Why? - Read some mailing lists... And this is commonly the question of religion. and i'd recommend postfix. trying hard to stay away from a religious war, i am keeping this as factual as possible. postfix and qmail don't really have any functional differences. both can do the same, both have the same features, and both are very powerful and cool. however, they use completely different configuration paradigms, and while there is little to be said against doing it the qmail-way, postfix seems more intuitive to the newbie who's always only worried about configuration files. qmail does not have a configuration file like postfix, it uses a mixture of directory hierarchies, filenames, and contents to configure the mail server. once you understood the paradigm, you can do whatever you want, as said. if you aren't used to qmail, then it will have a steeper learning curve than postfix. i am sure some folks will disagree. the only way to answer it for yourself is to try them both. finally, it has to be mentioned that qmail's author, DJ Bernstein, is an excellent coder, just like postfix's author Wietse Venema. postfix is fully open-source and GPL, while qmail has a rather ridiculous propriertary license, preventing a binary distributions as we have it with .deb packages. the qmail package maintainer has done a good job though, and while you need some -dev libraries to install qmail, it's more or less automatic. *but*, and this is something that i probably shouldn't state here, but which i feel important. it's not about the functionality of the software, it's about the principle. Wietse, the author of postfix, advertises it as competitor of qmail, not enemy. DJB, the author of qmail, on the other hand, chooses to be present on the mailing lists of competing software (like postfix-users or bind9-users) and publicly *trashes* the competing software, constantly telling the users that his product, qmail or djbdns respectively, doesn't suffer from such childish sicknesses, and that instead of using the mailing list to solve their problems, they should switch to his software and not experience the problems. for me, that's reason enough not to support him. you are free to make up your own will though. especially because even though his software is good, it is not flawless! -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck die wahrheit ist selten auf seiten der wahrscheinlichkeit. -- heinrich v. kleist msg05436/pgp0.pgp Description: PGP signature
Re: Mail server anti-virus software?
and i'd recommend postfix. I run postfix + kavcheck + avcheck (do a google and you'll probably find it). kavcheck's postfix implementation isn't very good, but the avcheck program comes complete with a howto do set it up chroot. Very nice. Combine this with crontab and you can update twice daily for the best results. Tarjei trying hard to stay away from a religious war, i am keeping this as factual as possible. postfix and qmail don't really have any functional differences. both can do the same, both have the same features, and both are very powerful and cool. however, they use completely different configuration paradigms, and while there is little to be said against doing it the qmail-way, postfix seems more intuitive to the newbie who's always only worried about configuration files. qmail does not have a configuration file like postfix, it uses a mixture of directory hierarchies, filenames, and contents to configure the mail server. once you understood the paradigm, you can do whatever you want, as said. if you aren't used to qmail, then it will have a steeper learning curve than postfix. i am sure some folks will disagree. the only way to answer it for yourself is to try them both. finally, it has to be mentioned that qmail's author, DJ Bernstein, is an excellent coder, just like postfix's author Wietse Venema. postfix is fully open-source and GPL, while qmail has a rather ridiculous propriertary license, preventing a binary distributions as we have it with .deb packages. the qmail package maintainer has done a good job though, and while you need some -dev libraries to install qmail, it's more or less automatic. *but*, and this is something that i probably shouldn't state here, but which i feel important. it's not about the functionality of the software, it's about the principle. Wietse, the author of postfix, advertises it as competitor of qmail, not enemy. DJB, the author of qmail, on the other hand, chooses to be present on the mailing lists of competing software (like postfix-users or bind9-users) and publicly *trashes* the competing software, constantly telling the users that his product, qmail or djbdns respectively, doesn't suffer from such childish sicknesses, and that instead of using the mailing list to solve their problems, they should switch to his software and not experience the problems. for me, that's reason enough not to support him. you are free to make up your own will though. especially because even though his software is good, it is not flawless! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
On Mon, 2002-01-21 at 23:40, martin f krafft wrote: snip nevertheless, leave a root console open on a production machine really just calls for trouble. imagine you are about to head for lunch with a friend, but you decide to check something in the server room quickly. while you stare at your Annex ports or your Cisco switch, your friend idles around and notices the root console. had there not been a root console, he would have never thought of doing what he now does, but since the prompt # is so inviting, he takes all of 20 seconds to install a backdoor in the system, binding a shell to a high port, installing his RSA identity.pub in /root/.ssh, scp'ing/email'ing /etc/shadow to himself etc. Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. snipped useful discussion of an exploit i think that you have a conceptual problem with what a server and a workstation are, and their differences, and what a superuser account is to be used for. in all but the rarest cases do production servers even have local accounts, and if, then usually without shell access. yes, i know that there are companies and institutions that provide shell access, but they usually have dedicated servers for that. Martin, I'm only an individual writing from one of my servers. And if I can save resources by using a server for a workstation as well I think that's OK. i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. I do not see that there is any significant security issue in logging in as root from a LOCAL console. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. Whenever I use a remote login procedure like SSH I log in as a user and then su to root when necessary. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: Here's a scenario where using su - could be less risky than always logging in as a user: First assume there is a local root vulnerability in the operating systems of two computers that can be accessed once a user level account has been obtained. Second, assume that the root passwords of both systems are very strong. Third, assume that the systems are logged into locally by a user/administrator. However they are connected to the Internet and are providing Internet services (it's not the best security practice to allow remote logins when they are not necessary but it's still a plausible scenario). In the first system the administrator sets up a user account with an easy to remember password. Over time a cracker is able to guess this password and obtain local user and then root access to the computer. In the second system the administrator sets up a user account with a randomly generated dual case alphanumeric password. The administrator has to write this password down to remember it. Consulting the document is a hassle so he/she decides to use su - to log in as the user instead. The remote cracker is never able to guess the user password and obtain user (then root) access to the system. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. Or to put it another way in some circumstances it may be superior for an administrator/user to only have to remember one long password than trying to remember two potentially less effective passwords. The user password can be even _unknown_ to the user. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Mail server anti-virus software?
Also, which mailserver would you recommend? (I have to learn one anyway.) I'd recommend QMail. Why? - Read some mailing lists... And this is commonly the question of religion. and i'd recommend postfix. trying hard to stay away from a religious war, i am keeping this as factual as possible. postfix and qmail don't really have any functional differences. both can do the same, both have the same features, and both are very powerful and cool. Frankly speaking, I have no experience with other MTAs. But qmail was installed by me from scratch, i.e. I really had no any experience with MTA or even Linux. however, they use completely different configuration paradigms, and while there is little to be said against doing it the qmail-way, postfix seems more intuitive to the newbie who's always only worried about configuration files. qmail does not have a configuration file like postfix, it uses a mixture of directory hierarchies, filenames, and contents to configure the mail server. once you understood the paradigm, you can do whatever you want, as said. Agreed. Not so simple for newbie. I've experienced some funny problems with one wrong letter in the config file :). *but*, and this is something that i probably shouldn't state here, but which i feel important. it's not about the functionality of the software, it's about the principle. ... Yes, I know about it. Agreed again. Somebody said agressive personality. That's the thing I newer forget to anybody too. Only one of us is God, so help if you can. OK, it is time to taste postfix. Knowledge - that's why I am spending my time on mailing lists! :). Thanks Martin! Anton. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: [ot] how to create a user that can't log in?
Please, everyone flame me if this is a blatant security hole Make your shell script secure, non-interuptable set the permission on it to 4750 (Setuid bit) with GROUP Being the group of people you want to run it and OWNER being the person you want to run it as. Phil -Original Message- From: Nathan E Norman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, 20 Jan 2002 14:05:44 -0600 Subject: Re: [ot] how to create a user that can't log in? No, it's not the right way. The daemons need to run as the project user, not the individual user. I know how to set up groups, permissions, etc. ... been doing that for several years now. What I'm wondering is if PAM or some other mechanism can be used to prevent a user from logging in via a network connection. It looks like people here don't know; that's fine, I'll continue researching. On Sun, Jan 20, 2002 at 01:39:48PM -0500, David Ehle wrote: LOL, talk about not seeing the forest for the tree's... Yeah. Do it the way he says. Its the right way of doing something like that. David. Alvin Oga wrote: hi ya nathan create a group proj add tom, dick, harry to belong to the proj group ( /etc/group ) - those NOT listed in proj will NOT be able to do anything make sure /home/project is owned by projectmanager and group proj make sure its chmod 775 or chmod 770 for /home/project make sure the shell for projectmanager is /dev/null ( no login shell ) each user ( tom, dick, harry ) can all run /home/project/scripts/start-me-up.sh w/o having to be projectmanager -- i claim there is no point to having a login account projectmanager/user if everybody can login into it... why bother ??? - you'd want to know who made the changes ... ( tom, dick, harry ) c ya alvin On Sun, 20 Jan 2002, Nathan E Norman wrote: Hi, I'm setting up a project for some friends. I want each of them to have their own account, but I want the project to be hosted (and run under) a seperate account. Each user should be able to su to the project account to restart daemons. No user should be able to log in as the project user. How do I set this up? Is it possible? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.1444 +0100]: Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. Martin, I'm only an individual writing from one of my servers. And if I can save resources by using a server for a workstation as well I think that's OK. okay. but your server has a permanent internet connection, and though you might not have mission-critical and confidential data, it is a prime target for hackers because of distributed denial of service attacks. so it needs to be secured, and you are on track. what's your server serving? i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. I do not see that there is any significant security issue in logging in as root from a LOCAL console. it depends on the environment, how many admins there are, and the physical security around you. with several tens of admins, it's important to keep track of every usage of root privileges with names and outside of those admins' control. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. Whenever I use a remote login procedure like SSH I log in as a user and then su to root when necessary. good. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: why post it then? This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. there's no excuse. enforce strong passwords. period. libpam-cracklib for a start, regular password cracking by john, account expiration etc. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck it is the mark of an educated mind to be able to entertain a thought without accepting it. -- aristoteles msg05441/pgp0.pgp Description: PGP signature
securid logins
assuming i have SecurID tokens with licenses, can i make linux authenticate based on these *without* the use of external or commercial software (like ACE/Server)? any experience anyone? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck all i ask of life is a constant and exaggerated sense of my own importance. msg05442/pgp0.pgp Description: PGP signature
Re: Re: [ot] how to create a user that can't log in?
also sprach Phillip Hofmeister [EMAIL PROTECTED] [2002.01.21.1511 +0100]: Please, everyone flame me if this is a blatant security hole consider yourself flamed. Make your [setuid] shell script secure, non-interuptable good luck. there is *a lot* of insecurity in a shell script. you have to be quite an expert to write them secure. and most of the flaws are not at all readily apparent... don't run shellscripts setuid or setgid. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck stay the patient course. of little worth is your ire. the network is down. msg05443/pgp0.pgp Description: PGP signature
Re: Re: [ot] how to create a user that can't log in?
Am Montag, 21. Januar 2002 15:21 schrieb martin f krafft: don't run shellscripts setuid or setgid. AFAIK Linux doesn't support setuid or setgid scripts, if you want to achieve things like this, you'll have to use an setgid or setuid interpreter (a.k.a. suidperl). Good Luck writing a secure setuid bash interpreter. Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tcl, tk and tix
The Tcl 8.3, Tk 8.3 and Tix 41 packages are not tuned to work ivery well with each other in woody. Using it out of box I get and starting tclsh % package require Tk couldn't load file /usr/lib/tk8.3/libtk8.3.so.1: /usr/lib/tk8.3/libtk8.3.so.1: cannot open shared object file: No such file or directory Closer examination reveals that libtk8.3.so.1 is in /usr/lib. Setting a link thus solves the problem. Now, trying Tix: % package require Tix can't find package Tix The package tix is found in /usr/share/tix4.1, which tclsh does not seem to know about. Why is tix in /usr/share, tk in /usr/lib anyway? Why not all packages related to each other under the same path? However I need to set a link ln -s /usr/share/tix4.1 /usr/lib/tix4.1 and patch together an pkgIndex.tcl file locate in the tix path together myself: # Tcl package index file, version 1.0 if {[package vcompare [info tclversion] 8.3] 0} return package ifneeded Tix 4.1 {load /usr/lib/libtix.so.4.1 Tix} Here again, libtix.so is found in the /usr/lib directory (not in /usr/share). I used tclsh because I found about the bugs when I tried to use tix in python. I pretty sure the corrections I made are not the best way to deal with the mentioned issues, but I am not into tcl at all. I am not sure if the packagers of tcl are reading this list. If somebody knows a better way to reach them, please write me or even better, forward it to the appropriate place. Mathias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tcl, tk and tix
Mathias Palm [EMAIL PROTECTED] cum veritate scripsit: I am not sure if the packagers of tcl are reading this list. If somebody knows a better way to reach them, please write me or even better, forward it to the appropriate place. Write to [EMAIL PROTECTED], and proceed to filing bugs against those packages. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
the su - user thread
this is a proof-of-concept post. it's a FreeBSD exploit, thus it may or may not have been, be, or will be applicable to Debian Linux or Linux in general. you have been warned. properly. http://www.aerasec.de/security/index.html?id=ae-200201-053lang=en -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck you're in college. you've made a mistake. msg05447/pgp0.pgp Description: PGP signature
Re: portscans and sniffing
Hi, AFAIK port scans are legal in Germany. It is even legal to break into a system, as long as you don't damage anything (which would be computer sabotage; but pay attention, killing a process with an exploit would already be damaging the system) or look at anything (which would be spying). Anyways, consult your lawyer about it, if you need a definite answer. best regards, Thiemo Nagel [EMAIL PROTECTED] schrieb: Hi all. I have startet a Security Company in Germany an now i have e few questions. Are ftp anonymous scans illegal? if it is, can i get an license to do penetrations test? thx for help, thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- == http://www.submitta.com Promote your website! Free download of cutting edge high per- formance multiple URL submission program. 600+ search engines. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Jan 20, 2002 at 11:04:13AM +1300, Adam Warner wrote: Hi everyone, ... The question I have is if I su - username and then browse the web, etc. is it impossible for a remote user who managed to gain access to that user session to become root by exiting out of the user account? Is there a reason to leave the parent shell around? How about, instead of su - - username exec su - username. If you are simply running a console as root that should remove any way of getting back to root from username. If you are running X as root, then you have bigger problems. donfede -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8TGDjSeRbV/op2s4RAooKAJ9WWW9snELp6NL+YgbfEbgk/100RgCdHzUd EPpCfFMyeB9L1ePRZk7mlq8= =J/aS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
root's home world readable
Hallo debian-sec folks, While I was checking up some configurations, I've noticed that the root's home directory /root is world readable... $ drwxr-xr-x2 root root 4.0k Jan 21 15:33 root This seems to be Debian's default configuration, because also on other Potato boxes I've found that same configuration. Well, as far as I can remember from the Slackware times, root's home dir wasn't world readable by default. Why has Debian choosen to let users access root's home ? Let me say I chmod 0700 /root, will I encounter any problems through some anacrom jobs or anything else ? I mean, when Debian set 0750 /root there must be a reason, ...isn't there ? Thanks for any help, Have a nice time and check out Lord of the Rings, it really rocks :) - Ivo -- »« »« »« »« »« »« »« »« »« »« »« »« »« »« »« Ivo Marino[EMAIL PROTECTED] UN*X Developer, running Debian GNU/Linux irc.OpenProjects.net #debian http://eimbox.org »« »« »« »« »« »« »« »« »« »« »« »« »« »« »« -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: root's home world readable
On Mon, Jan 21, 2002 at 07:54:03PM +0100, eim wrote: Why has Debian choosen to let users access root's home ? Why not? Debian doesn't put any sensitive files there. In fact, it doesn't put anything notable there at all. Let me say I chmod 0700 /root, will I encounter any problems through some anacrom jobs or anything else ? Since nothing important is installed in /root, there should be no problems with denying access. I mean, when Debian set 0750 /root there must be a reason, ...isn't there ? Presumably the reason is that, traditionally, Unix systems have only taken away access to sensitive information. There's nothing sensitive in /root/, so there's no reason to deny access to it. Also, since it's not usually recommended to work as root, there's really no reason for anything to wind up in /root at all, sensitive or otherwise. Have a nice time and check out Lord of the Rings, it really rocks :) Agreed. I must go see it again soon. 8^) noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html msg05451/pgp0.pgp Description: PGP signature
Re: tcl, tk and tix
Oops, wrong thread, sorry about this Mathias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: root's home world readable
At 11:03 AM 1/21/2002, you wrote: On Mon, Jan 21, 2002 at 07:54:03PM +0100, eim wrote: Why has Debian choosen to let users access root's home ? Why not? Debian doesn't put any sensitive files there. In fact, it doesn't put anything notable there at all. There is at least one package in Debian that requires you to put sensitive information in /root. The mysql server package needs you to have a .my.cnf in the /root if you want the logs to rotate. The my.cnf contains the clear text version of the root password to the database. Cut from /etc/logrotate.d/mysql-server # If the root user has a password you have to create a # /root/.my.cnf configuration file with the following # content: Let me say I chmod 0700 /root, will I encounter any problems through some anacrom jobs or anything else ? Since nothing important is installed in /root, there should be no problems with denying access. I have changed /root to 0700 on all my installations because I am running mysql server. It hasn't broken anything. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: root's home world readable
On Mon, Jan 21, 2002 at 01:34:31PM -0800, Chris Francy wrote: There is at least one package in Debian that requires you to put sensitive information in /root. The mysql server package needs you to have a .my.cnf in the /root if you want the logs to rotate. The my.cnf contains the clear text version of the root password to the database. snip I have changed /root to 0700 on all my installations because I am running mysql server. It hasn't broken anything. Is there any reason you can't just chmod 0600 /root/.my.cnf, in that case? Clearly there are individual files that you don't want world-readable, but that's true for normal users' home dirs as well. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html msg05454/pgp0.pgp Description: PGP signature
Re: root's home world readable
Noah L. Meyerhans [EMAIL PROTECTED] writes: I have changed /root to 0700 on all my installations because I am running mysql server. It hasn't broken anything. Is there any reason you can't just chmod 0600 /root/.my.cnf, in that case? Clearly there are individual files that you don't want world-readable, but that's true for normal users' home dirs as well. Why do you want folks to be able to *see* that you have a .my.conf in there? Directory and file permissions work together; block r on the dir and the users won't be able to _ls_ in it. Block permissions on the file as well, and they won't be able to read it should they guess its existence. All to the good, as far as I'm concerned! ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: root's home world readable
Chris Francy [EMAIL PROTECTED] writes: There is at least one package in Debian that requires you to put sensitive information in /root. The mysql server package needs you to have a .my.cnf in the /root if you want the logs to rotate. The my.cnf contains the clear text version of the root password to the database. This is a bug. The file should be in /etc (if, as it sounds like, it's a system-wide configuration file). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: root's home world readable
On Mon, Jan 21, 2002 at 09:45:50PM +, Tim Haynes wrote: Is there any reason you can't just chmod 0600 /root/.my.cnf, in that case? Clearly there are individual files that you don't want world-readable, but that's true for normal users' home dirs as well. Why do you want folks to be able to *see* that you have a .my.conf in there? What difference does it make? They know you have an /etc/shadow, /var/mail/$USER, ~/.bash_history, etc etc etc. Those don't need to be in read-protected directories. They can 'ls' them all they want, but it won't get them anywhere. Directory and file permissions work together; block r on the dir and the users won't be able to _ls_ in it. Block permissions on the file as well, and they won't be able to read it should they guess its existence. All to the good, as far as I'm concerned! Multiple layers of security are one thing, but this doesn't get you anything. Compromise one layer and you've necessarily compromised the other. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html msg05457/pgp0.pgp Description: PGP signature
Re: root's home world readable
Noah L. Meyerhans [EMAIL PROTECTED] writes: On Mon, Jan 21, 2002 at 09:45:50PM +, Tim Haynes wrote: Is there any reason you can't just chmod 0600 /root/.my.cnf, in that case? Clearly there are individual files that you don't want world-readable, but that's true for normal users' home dirs as well. Why do you want folks to be able to *see* that you have a .my.conf in there? What difference does it make? They know you have an /etc/shadow, /var/mail/$USER, ~/.bash_history, etc etc etc. 1 out of 3 ain't bad, apparently. Those don't need to be in read-protected directories. They can 'ls' them all they want, but it won't get them anywhere. This is where the per-file permissions come in. See below. Directory and file permissions work together; block r on the dir and the users won't be able to _ls_ in it. Block permissions on the file as well, and they won't be able to read it should they guess its existence. All to the good, as far as I'm concerned! Multiple layers of security are one thing, but this doesn't get you anything. Compromise one layer and you've necessarily compromised the other. What makes you think .my.conf is the *only* thing I'm going to want to keep in /root/? Permissions on the directory are not only a necessary part of protecting the contents, but a forward-looking prevention against the day you choose to store your firewall.sh in there for all to see as well. And your ipv6.sh. And... ~Tim -- http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
On Tue, 2002-01-22 at 03:11, martin f krafft wrote: also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.1444 +0100]: Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. An amazing story. Did you ever find out why the intruder did that? What data he/she was after? Martin, I'm only an individual writing from one of my servers. And if I can save resources by using a server for a workstation as well I think that's OK. okay. but your server has a permanent internet connection, and though you might not have mission-critical and confidential data, it is a prime target for hackers because of distributed denial of service attacks. so it needs to be secured, and you are on track. what's your server serving? It is secured in a respectible manner. Ports 53 (bind9 DNS), 80 (Apache/Zope), 113 (no server just a connection refused) and 119 (local news server) are accessible to the world. Non-LAN logins are blocked. I also enable ICMP echo-requests because I believe it is a responsible service to provide. I attempt to keep up to date with security releases. Yes I am on track. You could suggest that I chroot (jail) bind 9 and have a better log analysis policy. i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. I do not see that there is any significant security issue in logging in as root from a LOCAL console. it depends on the environment, how many admins there are, and the physical security around you. with several tens of admins, it's important to keep track of every usage of root privileges with names and outside of those admins' control. In other words it's not relevant to my situation. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. Whenever I use a remote login procedure like SSH I log in as a user and then su to root when necessary. good. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: why post it then? Because you will have to weigh up the costs and benefits in the scenario like any good security expert. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. there's no excuse. enforce strong passwords. period. libpam-cracklib for a start, regular password cracking by john, account expiration etc. So this is an admission that in my contrived scenario the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember.? You just rewrote the scenario because you didn't like the idea of someone using an easy to use password--even though this is a relatively common scenario. What you provided is a solution to overcoming the problem. Not a comment on which scenario was more secure. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
On Tue, 2002-01-22 at 07:41, Federico Grau wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Jan 20, 2002 at 11:04:13AM +1300, Adam Warner wrote: Hi everyone, ... The question I have is if I su - username and then browse the web, etc. is it impossible for a remote user who managed to gain access to that user session to become root by exiting out of the user account? Is there a reason to leave the parent shell around? How about, instead of su - - username exec su - username. If you are simply running a console as root that should remove any way of getting back to root from username. If you are running X as root, then you have bigger problems. Federico, are you saying that if you su - to a user account (from root) and then start X that you are running X as root? If so that is a major problem. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mail server anti-virus software?
Greetings! On Mon, Jan 21, 2002 at 12:17:56PM +0200, Mikko Kilpikoski wrote: Well, here's my list of questions: Are there any free or no cost solutions (for corporate use)? For exim there is a filter which rejects all mail with directly executable files attached (ftp.exim.org/pub/filter - or similar). While not a virus filter it helps protect from stupid mistakes and overly (virus-)friendly mail clients. Should I go for McAfee, Kaspersky, H+BEDV, Trend Micro, F-Secure or something else? At work we use Trend with good success. It comes with builtin HTTP proxy and mail gate, so no manual configuration of mail servers needed for integration. Web interface is nice for Win*-spoiled admins, but plain config file editing works just as well. Also, which mailserver would you recommend? (I have to learn one anyway.) Postfix or exim. I found exim to be easier to set up - which might have to do with the not-so-good/extensive docs for postfix... Bye Volker -- Volker Tanger [EMAIL PROTECTED] -===- Research Development Division, WYAE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
martin f krafft wrote: also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.1444 +0100]: Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. Woah, that does sound a little far-fetched. I am assuming there is a little more to this story? I would think most *physical* intruders would try to nab DVD players, valuables, and money, not wander into a spare room and whip out some UNIX skills to break into machines. Well, if I were a robber, I would certainly just take machines and not concern myself with having remote access to them. Hmm, likely most people that know about init=/bin/sh have enough money to not have to break into places. Hmm, maybe the recession has made life so bad that script kiddies can't afford ISPs any longer, and thus need to have physical access to machines to do their IRC takeovers... There has to be more there, like you offended someone you know and he wandered to your house or your some sort of spy that knows people that do that stuff ;) Just a little healthy skepticism... -A. Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.2304 +0100]: as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. An amazing story. Did you ever find out why the intruder did that? What data he/she was after? no. he claims that all he wanted was root access to the box for a dDoS (it was on a 2mbps line). i think he was after money, but then turned into an opportunist as he couldn't find any. when will people finally realize that i am poor :) It is secured in a respectible manner. Ports 53 (bind9 DNS), 80 (Apache/Zope), 113 (no server just a connection refused) and 119 (local news server) are accessible to the world. Non-LAN logins are blocked. if your news server is non-root and chrooted as well as bind, and your apache does not use suexec and runs as www-data (and is reasonably new), then you should have little to fear. then we could settle this discussion as i think we can endlessly toss the turns. there is no right and wrong in security, only gut feelings (gosh, i am repeating myself, and it isn't even that good of a quote...) I also enable ICMP echo-requests because I believe it is a responsible service to provide. why? I attempt to keep up to date with security releases. you also run Debian. that's a good start ;) Yes I am on track. You could suggest that I chroot (jail) bind 9 and have a better log analysis policy. you *should*, especially because with a 2.4 kernel, you can do so in 10 commands. it depends on the environment, how many admins there are, and the physical security around you. with several tens of admins, it's important to keep track of every usage of root privileges with names and outside of those admins' control. In other words it's not relevant to my situation. okay, fine. you win. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: why post it then? Because you will have to weigh up the costs and benefits in the scenario like any good security expert. i never said i am good. nevertheless, read on below. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. there's no excuse. enforce strong passwords. period. libpam-cracklib for a start, regular password cracking by john, account expiration etc. So this is an admission that in my contrived scenario the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember.? there is nothing to be said against keeping a hint to the password written down somewhere. for instance, i once had to remember the weekly changing security code of a lab, which was four digits. i am *really* good with numbers, but not if they change every week, and so i simply carried a piece of paper around with me with a matrix. say the number was 4723, my paper would look like this: 2830 6121 2979 0045 and all i had to remember was: third column, upside down. granted, even that could be considered insecure, but you always have to trade off security vs. necessity, as you stated. you can apply the same to root passwords. as long as you don't write on the paper: root's password to mymachine.mydomain.net [124.45.26.117] (hidden telnet at port 31776), and possibly encrypt the passsword in a very custom and non-algorithmic way as i did above, you'd be safe. oh, and as long as you don't pull it out in front of the machine and type it off. go to the bathroom or something, and remember it for the 60 seconds it takes you to get back and onto a shell prompt. see, my thing with security is that i am actually well aware of security flaws and considerations, but i don't employ 100% secure means for everything. simply because it's overkill. i don't keep my passwords on a post-it on the screen, i do use SecurID or S/Key whenever possible, but i have had other security people or paranoid admins scream at me. usability and security are mutually exclusive, but you can find a way to combine both with respect to what the environment needs, and i am really good at that actually. and the last time i entered a root password anywhere was like 3 months ago, thanks to properly configured sudo installations. You just rewrote the scenario because you didn't like the idea
Re: [d-security] Re: root's home world readable
On Mon, Jan 21, 2002 at 01:46:58PM -0800, Thomas Bushnell, BSG wrote: There is at least one package in Debian that requires you to put sensitive information in /root. The mysql server package needs you to have a .my.cnf in the /root if you want the logs to rotate. The my.cnf contains the clear text version of the root password to the database. This is a bug. The file should be in /etc (if, as it sounds like, it's a system-wide configuration file). It is not (a system wide configuration file) but at least in recent versions you can archive the needed functionality by creating a debian system user with sufficent privileges. This is planned but I though I implement it after the next freeze (well err, that's what I though half a year ago, probably the main freeze is far enough away to change it before testing will be released) bye, -christian- / mysql maintainer aka the one to blame -- I am Homer of Borg. Resistance is futi... M, donuts! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
also sprach Dave Kline [EMAIL PROTECTED] [2002.01.21.2340 +0100]: Woah, that does sound a little far-fetched. I am assuming there is a little more to this story? I would think most *physical* intruders would try to nab DVD players, valuables, and money, not wander into a spare room and whip out some UNIX skills to break into machines. Well, if I were a robber, I would certainly just take machines and not concern myself with having remote access to them. Hmm, likely most people that know about init=/bin/sh have enough money to not have to break into places. i don't have a DVD player, i have no valuables, and definitely no money. all my machines are physically locked down though. and no, there wasn't more to the story. There has to be more there, like you offended someone you know and he wandered to your house or your some sort of spy that knows people that do that stuff ;) Just a little healthy skepticism... maybe it's just me, but i have the weirdest shit happening to me. skepticism accepted, i don't have anything more to say though. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck 1-800-psych hello, welcome to the psychiatric hotline. if you are obsessive-compulsive, please press 1 repeatedly. msg05465/pgp0.pgp Description: PGP signature
Re: [d-security] Re: root's home world readable
Christian Hammers [EMAIL PROTECTED] writes: On Mon, Jan 21, 2002 at 01:46:58PM -0800, Thomas Bushnell, BSG wrote: There is at least one package in Debian that requires you to put sensitive information in /root. The mysql server package needs you to have a .my.cnf in the /root if you want the logs to rotate. The my.cnf contains the clear text version of the root password to the database. This is a bug. The file should be in /etc (if, as it sounds like, it's a system-wide configuration file). It is not (a system wide configuration file) but at least in recent versions you can archive the needed functionality by creating a debian system user with sufficent privileges. This is planned but I though I implement it after the next freeze (well err, that's what I though half a year ago, probably the main freeze is far enough away to change it before testing will be released) What? If it's a way to get the logs to rotate, that sure sounds like a system-wide option. If it's a root password to a system-wide database, then that's also a system-wide option. I don't know what archive the needed functionality means. If these are system-wide options, they belong in /etc. They do not belong in ~root, and they do not belong in ~debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.2307 +0100]: Federico, are you saying that if you su - to a user account (from root) and then start X that you are running X as root? If so that is a major problem. no, he actually says that with exec, you should theoretically be more secure as in a root-su-user scenario, because after you exec, the root shell is gone. it's an interesting proposal and when i have time, i would like to look at the user status after su vs. a normal login to see if there's *any* difference. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck i'd rather be riding a high speed tractor with a beer on my lap, and a six pack of girls next to me. msg05467/pgp0.pgp Description: PGP signature
Re: [d-security] Re: root's home world readable
Hi On Mon, Jan 21, 2002 at 03:23:15PM -0800, Thomas Bushnell, BSG wrote: If it's a way to get the logs to rotate, that sure sounds like a system-wide option. If it's a root password to a system-wide database, then that's also a system-wide option. The password for the mysql root user is not property of the system wide configuration as I can't force the user to change a file in /etc every time they change the users password and, due to mysqls default to use the mysql user of the same name as the system user you are logged in it would be unconvinient for the user to have to log into mysql as something other. With functionality I not only meant log rotating but also shutting down the server at upgrades and deinstalles as I don't want to just kill the processes although last time I checked the code was the same. So I end up with a debian specific user with shutdown/reload privileges that's created with a random (saved) password at installtime as the best solution, or? bye, -christian- P.S.: Further discussion via BTS (off topic here). thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Local exploit in courier-mta package
Package: courier-mta Version: 0.36.1-2 Severity: critical A hand-crafted .courier file can be used to insert \r characters in the message queue file. A bug in the function that reads message queue files subsequently results in memory corruption. This exploit is fixed in 0.37.2 upstream, I'll upload an upgraded version ASAP. Ciao Racke -- For projects and other business stuff please refer to COBOLT NetServices (URL: http://www.cobolt.net; Email: [EMAIL PROTECTED]; Phone: 0041-1-3884400) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: securid logins
On Mon, Jan 21, 2002 at 06:16:34AM -0800, martin f krafft wrote: assuming i have SecurID tokens with licenses, can i make linux authenticate based on these *without* the use of external or commercial software (like ACE/Server)? any experience anyone? I don't think so. But I'd be interested in the responses as well. -- Share and Enjoy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: securid logins
Previously Petro wrote: I don't think so. But I'd be interested in the responses as well. There is some support in PAM and in OpenSSH. I have a cryptocard RB-1 token now which I intent to get working with OpenSSH at least once I have some free time to spent on it. Wichert. -- _ [EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
also sprach Christian Jaeger [EMAIL PROTECTED] [2002.01.22.0111 +0100]: Now you may say don't build packages as root, use fakeroot instead. Well I have always used it, and somehow thought I'm safe, but I'm not: the permissions modes (like 4755) make it through to the real filesystem, only the owner/group is faked. Thus I'm left with binaries setuid *me* or setgid *my group* afterwards. That's only slightly better than root, since I'm also the admin and once my account is hijacked it's not far from being root. why are your build directories accessible to the world? a simple chmod 0700 ~/deb/build fixes all these problems for me, and persistently... It seems the only way around this (currently) is to compile packages in a directory with 0700 permissions. and? what's so wrong with that? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck it appears that pl/i (and its dialects) is, or will be, the most widely used higher level language for systems programming. -- j. sammet msg05475/pgp0.pgp Description: PGP signature
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
At 1:19 Uhr +0100 22.01.2002, martin f krafft wrote: why are your build directories accessible to the world? a simple chmod 0700 ~/deb/build fixes all these problems for me, and persistently... They were accessible, because I didn't realize that there was a risk, and because it's convenient when other users on the system can grab the finished .deb's from the build dir (to install them on their machine) without me having to move them to a public place. Christian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: securid logins
also sprach Wichert Akkerman [EMAIL PROTECTED] [2002.01.22.0122 +0100]: There is some support in PAM and in OpenSSH. I have a cryptocard RB-1 token now which I intent to get working with OpenSSH at least once I have some free time to spent on it. yeah, but that's OpenSSH only (which *is* 99% of what you'd use it for). but i'd love a PAM-based solution. maybe i should port it. if openssh can do it, then the code is open-source, then pam should be able to do it too. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck de gustibus non est disputandum. msg05477/pgp0.pgp Description: PGP signature
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
also sprach Christian Jaeger [EMAIL PROTECTED] [2002.01.22.0129 +0100]: They were accessible, because I didn't realize that there was a risk, and because it's convenient when other users on the system can grab the finished .deb's from the build dir (to install them on their machine) without me having to move them to a public place. yes, that's UNIX life. convenience ~ security^-1, where operator~ here is proportional -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck i have the power to channel my imagination into ever-soaring levels of suspicion and paranoia. msg05479/pgp0.pgp Description: PGP signature
Re: su - user question
On Tue, 2002-01-22 at 12:21, martin f krafft wrote: also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.2307 +0100]: Federico, are you saying that if you su - to a user account (from root) and then start X that you are running X as root? If so that is a major problem. no, he actually says that with exec, you should theoretically be more secure as in a root-su-user scenario, because after you exec, the root shell is gone. it's an interesting proposal and when i have time, i would like to look at the user status after su vs. a normal login to see if there's *any* difference. That would be an interesting analysis. I enjoyed your long email discussion and understood it, thanks. I set out to find out if su - username was a large security risk in the circumstances I outlined and it appears it is not. And with Federico's proposal of using exec (which you helped me understand) it may even be identically secure. Please CC me your analysis if you find time so there's no chance I miss it. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
yes, that's UNIX life. convenience ~ security^-1, I just wanted to point it out here, since I wasn't sure whether I should file a bug report against fakeroot for writing suid through, or one for the fakeroot manpage not mentioning the danger, or one for dpkg-buildpackage either for not mentioning the risk in the manpage, or for not warning that the directory I'm using is world accessible, or one for the debhelper scripts (? or? I don't know the build process enough) for not creating the tmp folders 0700. chj.- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
For the non-mathmatical, or rather gramatical, style to say it, I use the phrase: Security is Inconvenient. The first time I say it to someone, they usually pause for a moment, digest it, and it really helps in further discussions about what to do about It's my answer, for instance, when someone notices just how much I type to open an SSH session. Wow, that's a long password. Yep, security is inconvenient. Sometimes this leads to *their* inquiring as to what it buys, and leads to another informed user who doesn't feel pressured. It isn't just UNIX, have you ever looked at how every openable thing on a Catarpiller earth-moving machine has a way to padlock it closed? One key for simple operation, another key for routine engine maintenance, maybe a pass-key (su) for the shop forman, etc... Curt- -Original Message- From: martin f krafft [mailto:[EMAIL PROTECTED]] ... yes, that's UNIX life. convenience ~ security^-1, where operator~ here is proportional -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck i have the power to channel my imagination into ever-soaring levels of suspicion and paranoia. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
On Tue, Jan 22, 2002 at 01:11:18AM +0100, Christian Jaeger wrote: This can be a real security hole, at least when you are not aware of it (I have just discovered a working way to exploit it on one of my machines). And isn't that a bug in the package in question? :) -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the su - user thread [Potential Debian Security Issue]
On Tue, 2002-01-22 at 05:26, martin f krafft wrote: this is a proof-of-concept post. it's a FreeBSD exploit, thus it may or may not have been, be, or will be applicable to Debian Linux or Linux in general. you have been warned. properly. http://www.aerasec.de/security/index.html?id=ae-200201-053lang=en I realise now that I have witnessed this kind of issue before (In some circumstances, it's possible for a non-privileged process to have `root' as the login name returned by getlogin.) Here's how you can reproduce it (running Debian unstable): 1. Log in as root 2. su - user 3. startx (running KDE, not GNOME) 4. Click on the Control Center 5. There in the Control Center info box it will state that the user is root! Why does the KDE Control Center think the user is currently root? In contrast the GNOME Control Center properly identifies the username. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the su - user thread [Potential Debian Security Issue]
On Tue, Jan 22, 2002 at 05:11:45PM +1300, Adam Warner wrote: Why does the KDE Control Center think the user is currently root? In contrast the GNOME Control Center properly identifies the username. Perhaps KDE uses getlogin(2) ? -- Leo Howell M5AKW msg05485/pgp0.pgp Description: PGP signature
portscans and sniffing
Hi all. I have startet a Security Company in Germany an now i have e few questions. Are ftp anonymous scans illegal? if it is, can i get an license to do penetrations test? thx for help, thomas
Re: portscans and sniffing
On Mon, Jan 21, 2002 at 10:36:18AM +0100, [EMAIL PROTECTED] wrote: Hi all. I have startet a Security Company in Germany an now i have e few questions. First try learning how to write :) Are ftp anonymous scans illegal? That depends on what country the system is located in, but generally it is considere illegal to portscan or attemt to access systems you are not authorized to access. However there is hardly any enforcement of these rules. if it is, can i get an license to do penetrations test? I suggest you only scan systems you are authorized to scan by their respective owners (your clients) and keep well away from other people's boxes. Mark Janssen Unix / Linux, Open-Source and Internet Consultant @ SyConOS IT E-mail: mark(at)markjanssen.nl / maniac(at)maniac.nl GnuPG Key Id: 357D2178 Web: Maniac.nl Unix-God.[Net|Org] MarkJanssen.[com|net|org|nl] SyConOS.[com|nl] pgprUazjdWeOD.pgp Description: PGP signature
Mail server anti-virus software?
Hi. I am setting up a (updating an existing) mail server at our company and would like to get some recommendations on what anti-virus software to run on the server. Currently I'm only looking for an on-demand mail scanner. (Maybe also with some kind of HTTP proxy support too. On-access scanning would also be a nice option, if I set up a samba server later.) I've tried to check a few websites for info on the commercial products, but I find them mostly confusing. Many have like one to a billion different 'products' or 'solutions' listed and I can't find the magic word linux anywhere either... :/ Well, here's my list of questions: Are there any free or no cost solutions (for corporate use)? Should I go for McAfee, Kaspersky, H+BEDV, Trend Micro, F-Secure or something else? What are you using? What's good or bad about them/it? Is there any comparisions of the products available in the web? Also, which mailserver would you recommend? (I have to learn one anyway.) Any good resources in the web? The server is running Debian Potato 2.2 with Bunk's kernel 2.4 updates. Current kernel is 2.2.19, but I will probably update it to 2.4(.17) soon to get ext3 support. The current MTA is sendmail 8.9.3-23. (The HTTP proxy solution that the company uses, is Apache 1.3.9-14 with proxy_module and Junkbuster 2.0-7.1) Thanks in advance, -- Mikko Kilpikoski
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.20.0245 +0100]: If the use of switch user has remote security implications I want to be able to understand them. The same as I want to be able to understand if leaving a root console open has remote security implications. Don't worry about local physical access. I want everyone to assume this is impossible. You have to assume this is impossible to not get sidetracked. the point is that you can't assume that. i hold network security seminars on a regular basis, and i research the facts every single time as well as possible, just to deliver the most accurate info to my students. excuse me if i can't provide you with a source (it was CERT), but my notes from the seminar that i was to hold today (it was canceled) state that 76% of all attacks are internal, and that around 40% of those are physical attacks, the remaining 60% are network attacks. okay, we are getting sidetracked, but local physical access is never impossible. and it's all too often a factor that is ignored. nevertheless, leave a root console open on a production machine really just calls for trouble. imagine you are about to head for lunch with a friend, but you decide to check something in the server room quickly. while you stare at your Annex ports or your Cisco switch, your friend idles around and notices the root console. had there not been a root console, he would have never thought of doing what he now does, but since the prompt # is so inviting, he takes all of 20 seconds to install a backdoor in the system, binding a shell to a high port, installing his RSA identity.pub in /root/.ssh, scp'ing/email'ing /etc/shadow to himself etc. no. he'd have to steal your actual tty session, and if all you are doing is surfing the web, then he can't really do that. however, which browser are you using? are you running X? why not use tty2-tty6 for a separate user login? Please don't worry about what else I could do. That's all sensible (unnecessary) advice. I want to understand this from a theoretical viewpoint. It gives me a very weird feeling in my intestines as well using su - to switch to a user account and I want to understand why. if you use the console only, and lynx or w3m to browse the web, you might be fine. if you start X as root, and run the browser as root, or if you somehow start X in general, security issues pop up everywhere. there's a reason why a server's a server and a workstation's a workstation. no, i can't give you a precise recipe or a definite this-is-how-it-is answer, simply because this is what security is all about: there is no right or wrong, there are simply gut feelings, and the good security administrators have sensible guts. it's really what makes security interesting and what keeps you young :) Can anyone provide a plausible scenario for how someone might be able to gain root level access because su - has been used to switch to a user account. Martin has already answered that your tty session would have to be stolen. How can you steal a tty session using only remote means? you'd have to be more specific as to what you are doing locally. X or not X? well, i guess that you're expecting a potential attacker not to know this. the only thing i can think of are escape sequences through /dev/tty, which cause the local shell to be trashed and possibly made to execute commands. whether you can harvest a privilege escalation from that, well, i am sure you can. i don't have a recipe off-hand. i just read ahead in the thread to see that someone else posted this already. woops. i think that you have a conceptual problem with what a server and a workstation are, and their differences, and what a superuser account is to be used for. in all but the rarest cases do production servers even have local accounts, and if, then usually without shell access. yes, i know that there are companies and institutions that provide shell access, but they usually have dedicated servers for that. i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] when I was a boy I was told that anybody could become president. now i'm
Re: Mail server anti-virus software?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Am Montag, 21. Januar 2002 11:17 schrieb Mikko Kilpikoski: Hi. I am setting up a (updating an existing) mail server at our company and would like to get some recommendations on what anti-virus software to run on the server. Currently I'm only looking for an on-demand mail scanner. (Maybe also with some kind of HTTP proxy support too. On-access scanning would also be a nice option, if I set up a samba server later.) I got somewhat confused :-) and did not reply to the list, but I suggested a look at http://www.openantivirus.org/ Ciao, Mirko - -- Mirko Wollenberg | Systemberater Kleine Rainstrasse 28 | 22765 Hamburg GSM: +49 170/ 554 78 72 http://www.mirkow.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8S/+E0uLUIzwK8qsRAj5SAJ9vXF5Q1vO+VpjKDpxtH/1oHYqLjwCZAXnV bf59p+IYpW/5MC2KCIrWE+g= =vpwh -END PGP SIGNATURE-
Re: Mail server anti-virus software?
also sprach Antropov Anton [EMAIL PROTECTED] [2002.01.21.1231 +0100]: Also, which mailserver would you recommend? (I have to learn one anyway.) I'd recommend QMail. Why? - Read some mailing lists... And this is commonly the question of religion. and i'd recommend postfix. trying hard to stay away from a religious war, i am keeping this as factual as possible. postfix and qmail don't really have any functional differences. both can do the same, both have the same features, and both are very powerful and cool. however, they use completely different configuration paradigms, and while there is little to be said against doing it the qmail-way, postfix seems more intuitive to the newbie who's always only worried about configuration files. qmail does not have a configuration file like postfix, it uses a mixture of directory hierarchies, filenames, and contents to configure the mail server. once you understood the paradigm, you can do whatever you want, as said. if you aren't used to qmail, then it will have a steeper learning curve than postfix. i am sure some folks will disagree. the only way to answer it for yourself is to try them both. finally, it has to be mentioned that qmail's author, DJ Bernstein, is an excellent coder, just like postfix's author Wietse Venema. postfix is fully open-source and GPL, while qmail has a rather ridiculous propriertary license, preventing a binary distributions as we have it with .deb packages. the qmail package maintainer has done a good job though, and while you need some -dev libraries to install qmail, it's more or less automatic. *but*, and this is something that i probably shouldn't state here, but which i feel important. it's not about the functionality of the software, it's about the principle. Wietse, the author of postfix, advertises it as competitor of qmail, not enemy. DJB, the author of qmail, on the other hand, chooses to be present on the mailing lists of competing software (like postfix-users or bind9-users) and publicly *trashes* the competing software, constantly telling the users that his product, qmail or djbdns respectively, doesn't suffer from such childish sicknesses, and that instead of using the mailing list to solve their problems, they should switch to his software and not experience the problems. for me, that's reason enough not to support him. you are free to make up your own will though. especially because even though his software is good, it is not flawless! -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] die wahrheit ist selten auf seiten der wahrscheinlichkeit. -- heinrich v. kleist pgpew1fIeLgwu.pgp Description: PGP signature
Re: Mail server anti-virus software?
and i'd recommend postfix. I run postfix + kavcheck + avcheck (do a google and you'll probably find it). kavcheck's postfix implementation isn't very good, but the avcheck program comes complete with a howto do set it up chroot. Very nice. Combine this with crontab and you can update twice daily for the best results. Tarjei trying hard to stay away from a religious war, i am keeping this as factual as possible. postfix and qmail don't really have any functional differences. both can do the same, both have the same features, and both are very powerful and cool. however, they use completely different configuration paradigms, and while there is little to be said against doing it the qmail-way, postfix seems more intuitive to the newbie who's always only worried about configuration files. qmail does not have a configuration file like postfix, it uses a mixture of directory hierarchies, filenames, and contents to configure the mail server. once you understood the paradigm, you can do whatever you want, as said. if you aren't used to qmail, then it will have a steeper learning curve than postfix. i am sure some folks will disagree. the only way to answer it for yourself is to try them both. finally, it has to be mentioned that qmail's author, DJ Bernstein, is an excellent coder, just like postfix's author Wietse Venema. postfix is fully open-source and GPL, while qmail has a rather ridiculous propriertary license, preventing a binary distributions as we have it with .deb packages. the qmail package maintainer has done a good job though, and while you need some -dev libraries to install qmail, it's more or less automatic. *but*, and this is something that i probably shouldn't state here, but which i feel important. it's not about the functionality of the software, it's about the principle. Wietse, the author of postfix, advertises it as competitor of qmail, not enemy. DJB, the author of qmail, on the other hand, chooses to be present on the mailing lists of competing software (like postfix-users or bind9-users) and publicly *trashes* the competing software, constantly telling the users that his product, qmail or djbdns respectively, doesn't suffer from such childish sicknesses, and that instead of using the mailing list to solve their problems, they should switch to his software and not experience the problems. for me, that's reason enough not to support him. you are free to make up your own will though. especially because even though his software is good, it is not flawless!
Re: su - user question
On Mon, 2002-01-21 at 23:40, martin f krafft wrote: snip nevertheless, leave a root console open on a production machine really just calls for trouble. imagine you are about to head for lunch with a friend, but you decide to check something in the server room quickly. while you stare at your Annex ports or your Cisco switch, your friend idles around and notices the root console. had there not been a root console, he would have never thought of doing what he now does, but since the prompt # is so inviting, he takes all of 20 seconds to install a backdoor in the system, binding a shell to a high port, installing his RSA identity.pub in /root/.ssh, scp'ing/email'ing /etc/shadow to himself etc. Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. snipped useful discussion of an exploit i think that you have a conceptual problem with what a server and a workstation are, and their differences, and what a superuser account is to be used for. in all but the rarest cases do production servers even have local accounts, and if, then usually without shell access. yes, i know that there are companies and institutions that provide shell access, but they usually have dedicated servers for that. Martin, I'm only an individual writing from one of my servers. And if I can save resources by using a server for a workstation as well I think that's OK. i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. I do not see that there is any significant security issue in logging in as root from a LOCAL console. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. Whenever I use a remote login procedure like SSH I log in as a user and then su to root when necessary. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: Here's a scenario where using su - could be less risky than always logging in as a user: First assume there is a local root vulnerability in the operating systems of two computers that can be accessed once a user level account has been obtained. Second, assume that the root passwords of both systems are very strong. Third, assume that the systems are logged into locally by a user/administrator. However they are connected to the Internet and are providing Internet services (it's not the best security practice to allow remote logins when they are not necessary but it's still a plausible scenario). In the first system the administrator sets up a user account with an easy to remember password. Over time a cracker is able to guess this password and obtain local user and then root access to the computer. In the second system the administrator sets up a user account with a randomly generated dual case alphanumeric password. The administrator has to write this password down to remember it. Consulting the document is a hassle so he/she decides to use su - to log in as the user instead. The remote cracker is never able to guess the user password and obtain user (then root) access to the system. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. Or to put it another way in some circumstances it may be superior for an administrator/user to only have to remember one long password than trying to remember two potentially less effective passwords. The user password can be even _unknown_ to the user. Regards, Adam
RE: Mail server anti-virus software?
Also, which mailserver would you recommend? (I have to learn one anyway.) I'd recommend QMail. Why? - Read some mailing lists... And this is commonly the question of religion. and i'd recommend postfix. trying hard to stay away from a religious war, i am keeping this as factual as possible. postfix and qmail don't really have any functional differences. both can do the same, both have the same features, and both are very powerful and cool. Frankly speaking, I have no experience with other MTAs. But qmail was installed by me from scratch, i.e. I really had no any experience with MTA or even Linux. however, they use completely different configuration paradigms, and while there is little to be said against doing it the qmail-way, postfix seems more intuitive to the newbie who's always only worried about configuration files. qmail does not have a configuration file like postfix, it uses a mixture of directory hierarchies, filenames, and contents to configure the mail server. once you understood the paradigm, you can do whatever you want, as said. Agreed. Not so simple for newbie. I've experienced some funny problems with one wrong letter in the config file :). *but*, and this is something that i probably shouldn't state here, but which i feel important. it's not about the functionality of the software, it's about the principle. ... Yes, I know about it. Agreed again. Somebody said agressive personality. That's the thing I newer forget to anybody too. Only one of us is God, so help if you can. OK, it is time to taste postfix. Knowledge - that's why I am spending my time on mailing lists! :). Thanks Martin! Anton.
Re: Re: [ot] how to create a user that can't log in?
Please, everyone flame me if this is a blatant security hole Make your shell script secure, non-interuptable set the permission on it to 4750 (Setuid bit) with GROUP Being the group of people you want to run it and OWNER being the person you want to run it as. Phil -Original Message- From: Nathan E Norman [EMAIL PROTECTED] To: debian-security@lists.debian.org Date: Sun, 20 Jan 2002 14:05:44 -0600 Subject: Re: [ot] how to create a user that can't log in? No, it's not the right way. The daemons need to run as the project user, not the individual user. I know how to set up groups, permissions, etc. ... been doing that for several years now. What I'm wondering is if PAM or some other mechanism can be used to prevent a user from logging in via a network connection. It looks like people here don't know; that's fine, I'll continue researching. On Sun, Jan 20, 2002 at 01:39:48PM -0500, David Ehle wrote: LOL, talk about not seeing the forest for the tree's... Yeah. Do it the way he says. Its the right way of doing something like that. David. Alvin Oga wrote: hi ya nathan create a group proj add tom, dick, harry to belong to the proj group ( /etc/group ) - those NOT listed in proj will NOT be able to do anything make sure /home/project is owned by projectmanager and group proj make sure its chmod 775 or chmod 770 for /home/project make sure the shell for projectmanager is /dev/null ( no login shell ) each user ( tom, dick, harry ) can all run /home/project/scripts/start-me-up.sh w/o having to be projectmanager -- i claim there is no point to having a login account projectmanager/user if everybody can login into it... why bother ??? - you'd want to know who made the changes ... ( tom, dick, harry ) c ya alvin On Sun, 20 Jan 2002, Nathan E Norman wrote: Hi, I'm setting up a project for some friends. I want each of them to have their own account, but I want the project to be hosted (and run under) a seperate account. Each user should be able to su to the project account to restart daemons. No user should be able to log in as the project user. How do I set this up? Is it possible? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.1444 +0100]: Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. Martin, I'm only an individual writing from one of my servers. And if I can save resources by using a server for a workstation as well I think that's OK. okay. but your server has a permanent internet connection, and though you might not have mission-critical and confidential data, it is a prime target for hackers because of distributed denial of service attacks. so it needs to be secured, and you are on track. what's your server serving? i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. I do not see that there is any significant security issue in logging in as root from a LOCAL console. it depends on the environment, how many admins there are, and the physical security around you. with several tens of admins, it's important to keep track of every usage of root privileges with names and outside of those admins' control. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. Whenever I use a remote login procedure like SSH I log in as a user and then su to root when necessary. good. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: why post it then? This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. there's no excuse. enforce strong passwords. period. libpam-cracklib for a start, regular password cracking by john, account expiration etc. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] it is the mark of an educated mind to be able to entertain a thought without accepting it. -- aristoteles pgpyy1zWj35BE.pgp Description: PGP signature
securid logins
assuming i have SecurID tokens with licenses, can i make linux authenticate based on these *without* the use of external or commercial software (like ACE/Server)? any experience anyone? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] all i ask of life is a constant and exaggerated sense of my own importance. pgpXR1JoyKtAk.pgp Description: PGP signature
Re: Re: [ot] how to create a user that can't log in?
also sprach Phillip Hofmeister [EMAIL PROTECTED] [2002.01.21.1511 +0100]: Please, everyone flame me if this is a blatant security hole consider yourself flamed. Make your [setuid] shell script secure, non-interuptable good luck. there is *a lot* of insecurity in a shell script. you have to be quite an expert to write them secure. and most of the flaws are not at all readily apparent... don't run shellscripts setuid or setgid. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] stay the patient course. of little worth is your ire. the network is down. pgplk3V5z6Ldf.pgp Description: PGP signature
Re: Re: [ot] how to create a user that can't log in?
Am Montag, 21. Januar 2002 15:21 schrieb martin f krafft: don't run shellscripts setuid or setgid. AFAIK Linux doesn't support setuid or setgid scripts, if you want to achieve things like this, you'll have to use an setgid or setuid interpreter (a.k.a. suidperl). Good Luck writing a secure setuid bash interpreter. Peter
tcl, tk and tix
The Tcl 8.3, Tk 8.3 and Tix 41 packages are not tuned to work ivery well with each other in woody. Using it out of box I get and starting tclsh % package require Tk couldn't load file /usr/lib/tk8.3/libtk8.3.so.1: /usr/lib/tk8.3/libtk8.3.so.1: cannot open shared object file: No such file or directory Closer examination reveals that libtk8.3.so.1 is in /usr/lib. Setting a link thus solves the problem. Now, trying Tix: % package require Tix can't find package Tix The package tix is found in /usr/share/tix4.1, which tclsh does not seem to know about. Why is tix in /usr/share, tk in /usr/lib anyway? Why not all packages related to each other under the same path? However I need to set a link ln -s /usr/share/tix4.1 /usr/lib/tix4.1 and patch together an pkgIndex.tcl file locate in the tix path together myself: # Tcl package index file, version 1.0 if {[package vcompare [info tclversion] 8.3] 0} return package ifneeded Tix 4.1 {load /usr/lib/libtix.so.4.1 Tix} Here again, libtix.so is found in the /usr/lib directory (not in /usr/share). I used tclsh because I found about the bugs when I tried to use tix in python. I pretty sure the corrections I made are not the best way to deal with the mentioned issues, but I am not into tcl at all. I am not sure if the packagers of tcl are reading this list. If somebody knows a better way to reach them, please write me or even better, forward it to the appropriate place. Mathias
Re: tcl, tk and tix
Mathias Palm [EMAIL PROTECTED] cum veritate scripsit: I am not sure if the packagers of tcl are reading this list. If somebody knows a better way to reach them, please write me or even better, forward it to the appropriate place. Write to debian-user@lists.debian.org, and proceed to filing bugs against those packages. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
the su - user thread
this is a proof-of-concept post. it's a FreeBSD exploit, thus it may or may not have been, be, or will be applicable to Debian Linux or Linux in general. you have been warned. properly. http://www.aerasec.de/security/index.html?id=ae-200201-053lang=en -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] you're in college. you've made a mistake. pgpjllpgr8Ggz.pgp Description: PGP signature
Re: root's home world readable
On Mon, Jan 21, 2002 at 07:54:03PM +0100, eim wrote: Why has Debian choosen to let users access root's home ? Why not? Debian doesn't put any sensitive files there. In fact, it doesn't put anything notable there at all. Let me say I chmod 0700 /root, will I encounter any problems through some anacrom jobs or anything else ? Since nothing important is installed in /root, there should be no problems with denying access. I mean, when Debian set 0750 /root there must be a reason, ...isn't there ? Presumably the reason is that, traditionally, Unix systems have only taken away access to sensitive information. There's nothing sensitive in /root/, so there's no reason to deny access to it. Also, since it's not usually recommended to work as root, there's really no reason for anything to wind up in /root at all, sensitive or otherwise. Have a nice time and check out Lord of the Rings, it really rocks :) Agreed. I must go see it again soon. 8^) noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpP5ZEdUmY8w.pgp Description: PGP signature
Re: tcl, tk and tix
Oops, wrong thread, sorry about this Mathias
Re: root's home world readable
At 11:03 AM 1/21/2002, you wrote: On Mon, Jan 21, 2002 at 07:54:03PM +0100, eim wrote: Why has Debian choosen to let users access root's home ? Why not? Debian doesn't put any sensitive files there. In fact, it doesn't put anything notable there at all. There is at least one package in Debian that requires you to put sensitive information in /root. The mysql server package needs you to have a .my.cnf in the /root if you want the logs to rotate. The my.cnf contains the clear text version of the root password to the database. Cut from /etc/logrotate.d/mysql-server # If the root user has a password you have to create a # /root/.my.cnf configuration file with the following # content: Let me say I chmod 0700 /root, will I encounter any problems through some anacrom jobs or anything else ? Since nothing important is installed in /root, there should be no problems with denying access. I have changed /root to 0700 on all my installations because I am running mysql server. It hasn't broken anything. Chris
Re: root's home world readable
On Mon, Jan 21, 2002 at 01:34:31PM -0800, Chris Francy wrote: There is at least one package in Debian that requires you to put sensitive information in /root. The mysql server package needs you to have a .my.cnf in the /root if you want the logs to rotate. The my.cnf contains the clear text version of the root password to the database. snip I have changed /root to 0700 on all my installations because I am running mysql server. It hasn't broken anything. Is there any reason you can't just chmod 0600 /root/.my.cnf, in that case? Clearly there are individual files that you don't want world-readable, but that's true for normal users' home dirs as well. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpiu6s23J6vC.pgp Description: PGP signature
Re: root's home world readable
Noah L. Meyerhans [EMAIL PROTECTED] writes: I have changed /root to 0700 on all my installations because I am running mysql server. It hasn't broken anything. Is there any reason you can't just chmod 0600 /root/.my.cnf, in that case? Clearly there are individual files that you don't want world-readable, but that's true for normal users' home dirs as well. Why do you want folks to be able to *see* that you have a .my.conf in there? Directory and file permissions work together; block r on the dir and the users won't be able to _ls_ in it. Block permissions on the file as well, and they won't be able to read it should they guess its existence. All to the good, as far as I'm concerned! ~Tim -- http://spodzone.org.uk/
Re: root's home world readable
Chris Francy [EMAIL PROTECTED] writes: There is at least one package in Debian that requires you to put sensitive information in /root. The mysql server package needs you to have a .my.cnf in the /root if you want the logs to rotate. The my.cnf contains the clear text version of the root password to the database. This is a bug. The file should be in /etc (if, as it sounds like, it's a system-wide configuration file).
Re: root's home world readable
On Mon, Jan 21, 2002 at 09:45:50PM +, Tim Haynes wrote: Is there any reason you can't just chmod 0600 /root/.my.cnf, in that case? Clearly there are individual files that you don't want world-readable, but that's true for normal users' home dirs as well. Why do you want folks to be able to *see* that you have a .my.conf in there? What difference does it make? They know you have an /etc/shadow, /var/mail/$USER, ~/.bash_history, etc etc etc. Those don't need to be in read-protected directories. They can 'ls' them all they want, but it won't get them anywhere. Directory and file permissions work together; block r on the dir and the users won't be able to _ls_ in it. Block permissions on the file as well, and they won't be able to read it should they guess its existence. All to the good, as far as I'm concerned! Multiple layers of security are one thing, but this doesn't get you anything. Compromise one layer and you've necessarily compromised the other. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgppkuHFPi6Y8.pgp Description: PGP signature
Re: root's home world readable
Noah L. Meyerhans [EMAIL PROTECTED] writes: On Mon, Jan 21, 2002 at 09:45:50PM +, Tim Haynes wrote: Is there any reason you can't just chmod 0600 /root/.my.cnf, in that case? Clearly there are individual files that you don't want world-readable, but that's true for normal users' home dirs as well. Why do you want folks to be able to *see* that you have a .my.conf in there? What difference does it make? They know you have an /etc/shadow, /var/mail/$USER, ~/.bash_history, etc etc etc. 1 out of 3 ain't bad, apparently. Those don't need to be in read-protected directories. They can 'ls' them all they want, but it won't get them anywhere. This is where the per-file permissions come in. See below. Directory and file permissions work together; block r on the dir and the users won't be able to _ls_ in it. Block permissions on the file as well, and they won't be able to read it should they guess its existence. All to the good, as far as I'm concerned! Multiple layers of security are one thing, but this doesn't get you anything. Compromise one layer and you've necessarily compromised the other. What makes you think .my.conf is the *only* thing I'm going to want to keep in /root/? Permissions on the directory are not only a necessary part of protecting the contents, but a forward-looking prevention against the day you choose to store your firewall.sh in there for all to see as well. And your ipv6.sh. And... ~Tim -- http://spodzone.org.uk/
Re: su - user question
On Tue, 2002-01-22 at 03:11, martin f krafft wrote: also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.1444 +0100]: Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. An amazing story. Did you ever find out why the intruder did that? What data he/she was after? Martin, I'm only an individual writing from one of my servers. And if I can save resources by using a server for a workstation as well I think that's OK. okay. but your server has a permanent internet connection, and though you might not have mission-critical and confidential data, it is a prime target for hackers because of distributed denial of service attacks. so it needs to be secured, and you are on track. what's your server serving? It is secured in a respectible manner. Ports 53 (bind9 DNS), 80 (Apache/Zope), 113 (no server just a connection refused) and 119 (local news server) are accessible to the world. Non-LAN logins are blocked. I also enable ICMP echo-requests because I believe it is a responsible service to provide. I attempt to keep up to date with security releases. Yes I am on track. You could suggest that I chroot (jail) bind 9 and have a better log analysis policy. i don't have the time to research and present an escalation exploit at this moment, but i do want you to accept one point, which in itself will already flaw your approach of handling login and usage of the workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and it's an accounting thing. there's a reason why the group wheel exists on traditional UNIX systems (*why* does Linux *not* have it); noone without a local account should be allowed root, and it's good to know who became root when; to become root, you have to know two passwords *and* an account name. I do not see that there is any significant security issue in logging in as root from a LOCAL console. it depends on the environment, how many admins there are, and the physical security around you. with several tens of admins, it's important to keep track of every usage of root privileges with names and outside of those admins' control. In other words it's not relevant to my situation. you have it backwards. usually, you login as user and su to root. logging in as root and su'ing to a user is the wrong way around. i even think it's wrong to allow password-less su and suggest to disable it. Whenever I use a remote login procedure like SSH I log in as a user and then su to root when necessary. good. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: why post it then? Because you will have to weigh up the costs and benefits in the scenario like any good security expert. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. there's no excuse. enforce strong passwords. period. libpam-cracklib for a start, regular password cracking by john, account expiration etc. So this is an admission that in my contrived scenario the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember.? You just rewrote the scenario because you didn't like the idea of someone using an easy to use password--even though this is a relatively common scenario. What you provided is a solution to overcoming the problem. Not a comment on which scenario was more secure. Regards, Adam
Re: su - user question
On Tue, 2002-01-22 at 07:41, Federico Grau wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Jan 20, 2002 at 11:04:13AM +1300, Adam Warner wrote: Hi everyone, ... The question I have is if I su - username and then browse the web, etc. is it impossible for a remote user who managed to gain access to that user session to become root by exiting out of the user account? Is there a reason to leave the parent shell around? How about, instead of su - - username exec su - username. If you are simply running a console as root that should remove any way of getting back to root from username. If you are running X as root, then you have bigger problems. Federico, are you saying that if you su - to a user account (from root) and then start X that you are running X as root? If so that is a major problem. Regards, Adam
Re: Mail server anti-virus software?
Greetings! On Mon, Jan 21, 2002 at 12:17:56PM +0200, Mikko Kilpikoski wrote: Well, here's my list of questions: Are there any free or no cost solutions (for corporate use)? For exim there is a filter which rejects all mail with directly executable files attached (ftp.exim.org/pub/filter - or similar). While not a virus filter it helps protect from stupid mistakes and overly (virus-)friendly mail clients. Should I go for McAfee, Kaspersky, H+BEDV, Trend Micro, F-Secure or something else? At work we use Trend with good success. It comes with builtin HTTP proxy and mail gate, so no manual configuration of mail servers needed for integration. Web interface is nice for Win*-spoiled admins, but plain config file editing works just as well. Also, which mailserver would you recommend? (I have to learn one anyway.) Postfix or exim. I found exim to be easier to set up - which might have to do with the not-so-good/extensive docs for postfix... Bye Volker -- Volker Tanger [EMAIL PROTECTED] -===- Research Development Division, WYAE
Re: su - user question
martin f krafft wrote: also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.1444 +0100]: Martin, it's a server in my spare room :-) The only person installing a backdoor on the server would be an unlawful intruder. Or a cat who can type ;-) Your points are well taken and I would follow the same security practices as you. as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. Woah, that does sound a little far-fetched. I am assuming there is a little more to this story? I would think most *physical* intruders would try to nab DVD players, valuables, and money, not wander into a spare room and whip out some UNIX skills to break into machines. Well, if I were a robber, I would certainly just take machines and not concern myself with having remote access to them. Hmm, likely most people that know about init=/bin/sh have enough money to not have to break into places. Hmm, maybe the recession has made life so bad that script kiddies can't afford ISPs any longer, and thus need to have physical access to machines to do their IRC takeovers... There has to be more there, like you offended someone you know and he wandered to your house or your some sort of spy that knows people that do that stuff ;) Just a little healthy skepticism... -A. Dave
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.2304 +0100]: as sad as it sounds, unlawful intruders happen. this being a true story, i have 11 machines in my spare room, and my house was broken in once. the *only* thing the intruder did was reboot one of the machines (that was his mistake) and install a backdoor via init=/bin/sh at the boot prompt. my logs screamed (i have redundant logging), i found the backdoor, had a honeypot on, and didn't have to wait 3 hours for the intruder to try to login. he didn't have to wait 3 hours for the police to show up. An amazing story. Did you ever find out why the intruder did that? What data he/she was after? no. he claims that all he wanted was root access to the box for a dDoS (it was on a 2mbps line). i think he was after money, but then turned into an opportunist as he couldn't find any. when will people finally realize that i am poor :) It is secured in a respectible manner. Ports 53 (bind9 DNS), 80 (Apache/Zope), 113 (no server just a connection refused) and 119 (local news server) are accessible to the world. Non-LAN logins are blocked. if your news server is non-root and chrooted as well as bind, and your apache does not use suexec and runs as www-data (and is reasonably new), then you should have little to fear. then we could settle this discussion as i think we can endlessly toss the turns. there is no right and wrong in security, only gut feelings (gosh, i am repeating myself, and it isn't even that good of a quote...) I also enable ICMP echo-requests because I believe it is a responsible service to provide. why? I attempt to keep up to date with security releases. you also run Debian. that's a good start ;) Yes I am on track. You could suggest that I chroot (jail) bind 9 and have a better log analysis policy. you *should*, especially because with a 2.4 kernel, you can do so in 10 commands. it depends on the environment, how many admins there are, and the physical security around you. with several tens of admins, it's important to keep track of every usage of root privileges with names and outside of those admins' control. In other words it's not relevant to my situation. okay, fine. you win. Since you even think it's wrong to allow password-less su and suggest to disable it you're really going to like trying to refute this heretical scenario I created: why post it then? Because you will have to weigh up the costs and benefits in the scenario like any good security expert. i never said i am good. nevertheless, read on below. This indicates to me that the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember. there's no excuse. enforce strong passwords. period. libpam-cracklib for a start, regular password cracking by john, account expiration etc. So this is an admission that in my contrived scenario the increased risks of using su - to log in as a user may be offset by the decreased risks of a superior user password that you actually have to write down and consult to remember.? there is nothing to be said against keeping a hint to the password written down somewhere. for instance, i once had to remember the weekly changing security code of a lab, which was four digits. i am *really* good with numbers, but not if they change every week, and so i simply carried a piece of paper around with me with a matrix. say the number was 4723, my paper would look like this: 2830 6121 2979 0045 and all i had to remember was: third column, upside down. granted, even that could be considered insecure, but you always have to trade off security vs. necessity, as you stated. you can apply the same to root passwords. as long as you don't write on the paper: root's password to mymachine.mydomain.net [124.45.26.117] (hidden telnet at port 31776), and possibly encrypt the passsword in a very custom and non-algorithmic way as i did above, you'd be safe. oh, and as long as you don't pull it out in front of the machine and type it off. go to the bathroom or something, and remember it for the 60 seconds it takes you to get back and onto a shell prompt. see, my thing with security is that i am actually well aware of security flaws and considerations, but i don't employ 100% secure means for everything. simply because it's overkill. i don't keep my passwords on a post-it on the screen, i do use SecurID or S/Key whenever possible, but i have had other security people or paranoid admins scream at me. usability and security are mutually exclusive, but you can find a way to combine both with respect to what the environment needs, and i am really good at that actually. and the last time i entered a root password anywhere was like 3 months ago, thanks to properly configured sudo installations. You just rewrote the scenario because you didn't like the idea
Re: [d-security] Re: root's home world readable
On Mon, Jan 21, 2002 at 01:46:58PM -0800, Thomas Bushnell, BSG wrote: There is at least one package in Debian that requires you to put sensitive information in /root. The mysql server package needs you to have a .my.cnf in the /root if you want the logs to rotate. The my.cnf contains the clear text version of the root password to the database. This is a bug. The file should be in /etc (if, as it sounds like, it's a system-wide configuration file). It is not (a system wide configuration file) but at least in recent versions you can archive the needed functionality by creating a debian system user with sufficent privileges. This is planned but I though I implement it after the next freeze (well err, that's what I though half a year ago, probably the main freeze is far enough away to change it before testing will be released) bye, -christian- / mysql maintainer aka the one to blame -- I am Homer of Borg. Resistance is futi... M, donuts!
Re: su - user question
also sprach Dave Kline [EMAIL PROTECTED] [2002.01.21.2340 +0100]: Woah, that does sound a little far-fetched. I am assuming there is a little more to this story? I would think most *physical* intruders would try to nab DVD players, valuables, and money, not wander into a spare room and whip out some UNIX skills to break into machines. Well, if I were a robber, I would certainly just take machines and not concern myself with having remote access to them. Hmm, likely most people that know about init=/bin/sh have enough money to not have to break into places. i don't have a DVD player, i have no valuables, and definitely no money. all my machines are physically locked down though. and no, there wasn't more to the story. There has to be more there, like you offended someone you know and he wandered to your house or your some sort of spy that knows people that do that stuff ;) Just a little healthy skepticism... maybe it's just me, but i have the weirdest shit happening to me. skepticism accepted, i don't have anything more to say though. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] 1-800-psych hello, welcome to the psychiatric hotline. if you are obsessive-compulsive, please press 1 repeatedly. pgprvg8PsIhaE.pgp Description: PGP signature
Re: [d-security] Re: root's home world readable
Christian Hammers [EMAIL PROTECTED] writes: On Mon, Jan 21, 2002 at 01:46:58PM -0800, Thomas Bushnell, BSG wrote: There is at least one package in Debian that requires you to put sensitive information in /root. The mysql server package needs you to have a .my.cnf in the /root if you want the logs to rotate. The my.cnf contains the clear text version of the root password to the database. This is a bug. The file should be in /etc (if, as it sounds like, it's a system-wide configuration file). It is not (a system wide configuration file) but at least in recent versions you can archive the needed functionality by creating a debian system user with sufficent privileges. This is planned but I though I implement it after the next freeze (well err, that's what I though half a year ago, probably the main freeze is far enough away to change it before testing will be released) What? If it's a way to get the logs to rotate, that sure sounds like a system-wide option. If it's a root password to a system-wide database, then that's also a system-wide option. I don't know what archive the needed functionality means. If these are system-wide options, they belong in /etc. They do not belong in ~root, and they do not belong in ~debian.
Re: su - user question
also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.2307 +0100]: Federico, are you saying that if you su - to a user account (from root) and then start X that you are running X as root? If so that is a major problem. no, he actually says that with exec, you should theoretically be more secure as in a root-su-user scenario, because after you exec, the root shell is gone. it's an interesting proposal and when i have time, i would like to look at the user status after su vs. a normal login to see if there's *any* difference. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] i'd rather be riding a high speed tractor with a beer on my lap, and a six pack of girls next to me. pgp495ydNQEbM.pgp Description: PGP signature
mysql admin user (was: root's home world readable)
Hello On Mon, Jan 21, 2002 at 03:35:14PM -0800, Thomas Bushnell, BSG wrote: [cutted much to answer all below] So I end up with a debian specific user with shutdown/reload privileges that's created with a random (saved) password at installtime as the best solution, or? Nope. Probably the user should need to be root (or some other generic user), but the files that are manipulated to accomplish shutdown/reload and so forth should all be in /etc. Nope (to your nope, because what you argument does in no way contradict my proposals, and the english wasn't that bad :-)) But to clear things up: I create a Debian specific users with all privileges that my Debian scripts need and then store this user's password in plaintext (necessary) in /etc. That's all I need as mysql now lets me specify config files everywhere so I don't have to give them via command line or similar which show up in ps. I won't fiddle around with the (mysql)root's password outside of /root because a common admin wouldn't expect that. (All mysql clients default to connect you with your $USER name so root normally is mysql user root, too). So there really are no problems ( friendly, -christian- -- This doesn't belong to a security mailing list...
dpkg-buildpackage (-rfakeroot) leaves setuid binaries
This can be a real security hole, at least when you are not aware of it (I have just discovered a working way to exploit it on one of my machines). dpkg-buildpackage makes a semi-real make install into a sub directory of the debian/ directory in the source dir, and then tar's the installed files. The installed files have the real final permissions, which may include suid/sgid bits. The debian build programs do *NOT* protect the subdir, thus it may be entered by anyone on the system who has access to the source tree and he may execute the binaries therein. Since programs sometimes make assumptions about where they are installed, or which libraries they link at runtime, it is not safe to execute them from there. Now you may say don't build packages as root, use fakeroot instead. Well I have always used it, and somehow thought I'm safe, but I'm not: the permissions modes (like 4755) make it through to the real filesystem, only the owner/group is faked. Thus I'm left with binaries setuid *me* or setgid *my group* afterwards. That's only slightly better than root, since I'm also the admin and once my account is hijacked it's not far from being root. It seems the only way around this (currently) is to compile packages in a directory with 0700 permissions. I could think of two ways to improve this situation: a) change fakeroot so it doesn't write the set[gu]id bits to disk (esp. if the faked owner/group differs from the real owner/group). b) change the debian build process so it creates the temp folders with 0700 permissions. Christian. (BTW a somewhat similar problem (but not debian specific) exists with the perl CPAN module build process: -MCPAN is designed to work as root. It downloads the tarball, extracts it (with the user/group that the author packed them) as root, thus you are left with files belonging to random system users. -MCPAN doesn't take any precautions to protect the .cpan/build/ folder, thus with a bit luck some user on the system can modify the unpacked files before they are built/installed by root.)
Re: securid logins
On Mon, Jan 21, 2002 at 06:16:34AM -0800, martin f krafft wrote: assuming i have SecurID tokens with licenses, can i make linux authenticate based on these *without* the use of external or commercial software (like ACE/Server)? any experience anyone? I don't think so. But I'd be interested in the responses as well. -- Share and Enjoy.
Re: securid logins
Hi, Quoting martin f krafft ([EMAIL PROTECTED]): yeah, but that's OpenSSH only (which *is* 99% of what you'd use it for). but i'd love a PAM-based solution. maybe i should port it. if openssh can do it, then the code is open-source, then pam should be able to do it too. There are open source PAM modules for the RB-1, alongside the sshd patch. Both are outdated and need fixing-up for recent versions of pam/ssh, but they do contain the logic needed. I have succeeded in getting working authentication using the RB-1 with the vendor-supplied pam module, authenticating against a radius server (which was not what i was looking for :/ ) Greets, Robert -- Linux Generation encrypted mail preferred. finger [EMAIL PROTECTED] for my GnuPG/PGP key. Nuke the unborn gay female whales for Jesus. pgpp68h1IJ9M8.pgp Description: PGP signature
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
also sprach Christian Jaeger [EMAIL PROTECTED] [2002.01.22.0129 +0100]: They were accessible, because I didn't realize that there was a risk, and because it's convenient when other users on the system can grab the finished .deb's from the build dir (to install them on their machine) without me having to move them to a public place. yes, that's UNIX life. convenience ~ security^-1, where operator~ here is proportional -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] i have the power to channel my imagination into ever-soaring levels of suspicion and paranoia. pgpvyzvwUVPlk.pgp Description: PGP signature
Re: su - user question
On Tue, 2002-01-22 at 12:21, martin f krafft wrote: also sprach Adam Warner [EMAIL PROTECTED] [2002.01.21.2307 +0100]: Federico, are you saying that if you su - to a user account (from root) and then start X that you are running X as root? If so that is a major problem. no, he actually says that with exec, you should theoretically be more secure as in a root-su-user scenario, because after you exec, the root shell is gone. it's an interesting proposal and when i have time, i would like to look at the user status after su vs. a normal login to see if there's *any* difference. That would be an interesting analysis. I enjoyed your long email discussion and understood it, thanks. I set out to find out if su - username was a large security risk in the circumstances I outlined and it appears it is not. And with Federico's proposal of using exec (which you helped me understand) it may even be identically secure. Please CC me your analysis if you find time so there's no chance I miss it. Regards, Adam
Re: dpkg-buildpackage (-rfakeroot) leaves setuid binaries
yes, that's UNIX life. convenience ~ security^-1, I just wanted to point it out here, since I wasn't sure whether I should file a bug report against fakeroot for writing suid through, or one for the fakeroot manpage not mentioning the danger, or one for dpkg-buildpackage either for not mentioning the risk in the manpage, or for not warning that the directory I'm using is world accessible, or one for the debhelper scripts (? or? I don't know the build process enough) for not creating the tmp folders 0700. chj.-