portscans and sniffing

2002-01-21 Thread kuepper

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

2002-01-21 Thread Mark Janssen

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?

2002-01-21 Thread 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'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

2002-01-21 Thread martin f krafft

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?

2002-01-21 Thread Rob Weir

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?

2002-01-21 Thread Antropov Anton

 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?

2002-01-21 Thread Mirko Wollenberg

-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?

2002-01-21 Thread martin f krafft

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?

2002-01-21 Thread Tarjei



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

2002-01-21 Thread Adam Warner

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?

2002-01-21 Thread Antropov Anton

   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?

2002-01-21 Thread Phillip Hofmeister

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

2002-01-21 Thread martin f krafft

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

2002-01-21 Thread martin f krafft

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?

2002-01-21 Thread martin f krafft

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?

2002-01-21 Thread Peter Wiersig

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

2002-01-21 Thread Mathias Palm

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

2002-01-21 Thread Junichi Uekawa

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

2002-01-21 Thread martin f krafft

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

2002-01-21 Thread Thiemo Nagel


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

2002-01-21 Thread Federico Grau

-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

2002-01-21 Thread eim

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

2002-01-21 Thread Noah L. Meyerhans

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

2002-01-21 Thread Mathias Palm

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

2002-01-21 Thread Chris Francy


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

2002-01-21 Thread Noah L. Meyerhans

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

2002-01-21 Thread Tim Haynes

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

2002-01-21 Thread Thomas Bushnell, BSG

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

2002-01-21 Thread Noah L. Meyerhans

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

2002-01-21 Thread Tim Haynes

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

2002-01-21 Thread Adam Warner

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

2002-01-21 Thread Adam Warner

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?

2002-01-21 Thread Volker Tanger

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

2002-01-21 Thread Dave Kline

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

2002-01-21 Thread martin f krafft

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

2002-01-21 Thread Christian Hammers

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

2002-01-21 Thread martin f krafft

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

2002-01-21 Thread Thomas Bushnell, BSG

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

2002-01-21 Thread martin f krafft

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

2002-01-21 Thread Christian Hammers

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

2002-01-21 Thread Stefan Hornburg (Racke)

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

2002-01-21 Thread Petro

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

2002-01-21 Thread Wichert Akkerman

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

2002-01-21 Thread martin f krafft

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

2002-01-21 Thread Christian Jaeger

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

2002-01-21 Thread martin f krafft

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

2002-01-21 Thread martin f krafft

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

2002-01-21 Thread Adam Warner

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

2002-01-21 Thread Christian Jaeger

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

2002-01-21 Thread Howland, Curtis

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

2002-01-21 Thread Daniel Jacobowitz

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]

2002-01-21 Thread Adam Warner

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]

2002-01-21 Thread Leo Howell

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

2002-01-21 Thread kuepper
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

2002-01-21 Thread Mark Janssen
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?

2002-01-21 Thread 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'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

2002-01-21 Thread martin f krafft
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?

2002-01-21 Thread Mirko Wollenberg
-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?

2002-01-21 Thread martin f krafft
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?

2002-01-21 Thread Tarjei



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

2002-01-21 Thread Adam Warner
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?

2002-01-21 Thread Antropov Anton
   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?

2002-01-21 Thread Phillip Hofmeister
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

2002-01-21 Thread martin f krafft
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

2002-01-21 Thread martin f krafft
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?

2002-01-21 Thread martin f krafft
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?

2002-01-21 Thread Peter Wiersig
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

2002-01-21 Thread Mathias Palm
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

2002-01-21 Thread Junichi Uekawa
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

2002-01-21 Thread martin f krafft
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

2002-01-21 Thread Noah L. Meyerhans
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

2002-01-21 Thread Mathias Palm
Oops, wrong thread, sorry about this

Mathias



Re: root's home world readable

2002-01-21 Thread Chris Francy


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

2002-01-21 Thread Noah L. Meyerhans
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

2002-01-21 Thread Tim Haynes
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

2002-01-21 Thread Thomas Bushnell, BSG
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

2002-01-21 Thread Noah L. Meyerhans
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

2002-01-21 Thread Tim Haynes
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

2002-01-21 Thread Adam Warner
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

2002-01-21 Thread Adam Warner
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?

2002-01-21 Thread Volker Tanger
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

2002-01-21 Thread Dave Kline

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

2002-01-21 Thread martin f krafft
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

2002-01-21 Thread Christian Hammers
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

2002-01-21 Thread martin f krafft
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

2002-01-21 Thread Thomas Bushnell, BSG
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

2002-01-21 Thread martin f krafft
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)

2002-01-21 Thread Christian Hammers
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

2002-01-21 Thread Christian Jaeger
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

2002-01-21 Thread Petro
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

2002-01-21 Thread Robert van der Meulen
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

2002-01-21 Thread martin f krafft
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

2002-01-21 Thread Adam Warner
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

2002-01-21 Thread Christian Jaeger

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.-