Re: [suse-security] autorpm and latest secure files
I used autorpm to update all flies it could come up with for my 6.2 installation.
As pointed out this thread is off-topic, but there is one security-related aspect to it. For the autorpm-user to think about: How do you ensure what you update on your system is genuine, and not trojaned? Whether the update actually works is of secondary importance. Volker
I used autorpm to update all flies it could come up with for my 6.2 installation.
As pointed out this thread is off-topic, but there is one security-related aspect to it. For the autorpm-user to think about:
How do you ensure what you update on your system is genuine, and not trojaned? Whether the update actually works is of secondary importance.
Volker
The integrity problem that you mention is definitely not off-topic. :-) autorpm may be a bad idea unless the rpm packages are signed. This is planned for the near future in the SuSE distribution. Thanks, Roman. -- - - | Roman Drahtmüller <draht@suse.de> // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -
On Thu, 10 Aug 2000, Roman Drahtmueller wrote:
The integrity problem that you mention is definitely not off-topic. :-)
autorpm may be a bad idea unless the rpm packages are signed. This is planned for the near future in the SuSE distribution.
Well, maybe we are a bit paranoid since we had an incident this year. A hacker hijacked one of our user accounts and left traces of actions undertaken to gain root access. We discussed the aspect above several times... So here is may question to the real experts: What are the recomended steps to do security updates from FTP when there is no PGP signature in the files? You know there was this incident with tripwire on the dutch server that was hacked and trojaned as far as I remember. Is there a reason to worry about somebody being able to hack and trojan the security updates supplied via ftp AND to hack an change the md5 sums provided by SuSE at the same time? Or is this coincidence too far from being probable? Cheers, Thomas -- |--------------------------------------------------------------------------| | Thomas Forbriger email: Thomas.Forbriger@geophys.uni-stuttgart.de | | Universitaet Stuttgart - Institut fuer Geophysik | | Richard-Wagner-Str. 44 D-70184 Stuttgart Germany | | Tel ++49 (711) 121-3593 or 3422 or 3424 or 3590 | Fax ++49 (711) 2361218 | | http://www.geophys.uni-stuttgart.de/thof | | "... there's nothing more bizarre than reality..." (M. Kindermann) |
On Thu, Aug 10, 2000 at 21:25 +0200, Thomas Forbriger wrote:
What are the recomended steps to do security updates from FTP when there is no PGP signature in the files? You know there was this incident with tripwire on the dutch server that was hacked and trojaned as far as I remember. Is there a reason to worry about somebody being able to hack and trojan the security updates supplied via ftp AND to hack an change the md5 sums provided by SuSE at the same time? Or is this coincidence too far from being probable?
The solution would be to combine several methods of checking. Even if an attacker can compromise the data in a way that one algo still fits (MD5 is not 100% secure after all -- how do you want to have unique fingerprints for *any* data when you only have 128 bits to store them?) a second one (SHA1, RIPEMD160) probably fails. If you use tripwire, put another "tripwire alike" besides it. If you have an update package with no sig to check against, get it from different (independent) places and compare them. If the update is available in source form, try to read the diff against the former version. Even if you don't know the internals exactly, you would have recognized some unexpected "mail attacker@somewhere < /etc/shadow" commands in a compromised tcpd package. Don't rely on a single source, double check for consistency what you get from different directions. Make use of every hurdle you can stack up instead of thinking "one obstacle in the chain should suffice". And don't believe in "automated security". I feel quite strong about that automatic updates won't work without heavy human supervision. :) Having your system (potentially) damaged by a simple minded program sucking in every update unchecked just because "the file was there and I felt like applying it" is not fun. When something breaks, *I* want to be the reason why. :> virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
The solution would be to combine several methods of checking. Even if an attacker can compromise the data in a way that one algo still fits (MD5 is not 100% secure after all -- how do you want to have unique fingerprints for *any* data when you only have 128 bits to store them?) a second one (SHA1, RIPEMD160) probably fails.
Wrong answer. USE GNUPG. Ok the problem with MD5/SHA1/etc/etc is for each package I need to get you the package, and the sig securely. With GnuPG I need to get the key to you securely ONCE, i.e. SuSE ships the keys on the CD. SuSE cannot ship all the future MD5/SHA1/etc sums on the CD for obvious reasons.
And don't believe in "automated security". I feel quite strong about that automatic updates won't work without heavy human supervision. :) Having your system (potentially) damaged by a simple minded program sucking in every update unchecked just because "the file was there and I felt like applying it" is not fun. When something breaks, *I* want to be the reason why. :>
Security has to be automated as much as possible. What happens when companies roll out 5000 linux desktops? -Kurt
On Fri, Aug 11, 2000 at 14:17 -0600, Kurt Seifried wrote:
And don't believe in "automated security". I feel quite strong about that automatic updates won't work without heavy human supervision. :) Having your system (potentially) damaged by a simple minded program sucking in every update unchecked just because "the file was there and I felt like applying it" is not fun. When something breaks, *I* want to be the reason why. :>
Security has to be automated as much as possible. What happens when companies roll out 5000 linux desktops?
I guess I put it into the wrong words ... I meant that I don't believe in automatic upgrading from an external source. I want to be the instance making the decision about how and most of all _when_ to break a system (or to risk breaking it) by updating. Admittedly I've never been in the above position to handle a few thousands of installations. Neither did I get close to this in any way. :) But I could imagine grouping these machines and applying the updates in steps to see how they react. In a perfect world the updates only remove some remedies and plainly work. In the real world these updates have side effects and you don't want to break *all* machines at _once._ There have been - and always will be - updates which just don't work (quick response in an attempt to help before the "real" fix is found and tested) and updates which change some behaviour other software has to be obeying too. To put it short: At the very least I would like to to have a filter _which_ updates (of all the availables) get applied and _when_ I want to risk updating my machines. This involves a test beforehand on isolated machines to recognize when a fix for one thing breaks other things or doesn't fix something. I don't believe in a distributor to autodeliver updates to me, I still see this as a service and an offer and I'm still the one to accept or delay or reject. Of course(?) once I want to apply an update, I'm still free to do so automatically inside my reach, from a source *I* define and for a set of machines I declare (and these could be all machines, as well). We agree that physically stepping up in front of more than ten machines is something no admin would like to do and even doing so via network will raise the feeling "there should be a different way without me sitting here and waiting for the computer(s) to finish". :) And I'm aware that delayed application of available fixes to known problems leave a window of possible vulnerability. But I don't want to be forced to accept fixes' downsides just because a fix is published. Maybe we're talking about different granularity and release schemes here? Maybe you put more trust into the fix' publisher than I do? But surely I speak as someone who never had to handle more than some twenty machines at once. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
Perhaps something like this is what you're thinking of? http://www.infrastructures.org/papers/bootstrap/bootstrap.html I saw this the other week on RootPrompt, and thought it was pretty neat. I'd like to get there one day. Which will be one day _after_ I figure out how to get everything running the way I want it in the first place. By then, I may be too scared to tear up my hard work and start from scratch to do a complete overhaul to a system like that. But hopefully by then, LinuxNOW will be functional, w/ a SuSE version ;) Monte Gerhard Sittig wrote:
On Fri, Aug 11, 2000 at 14:17 -0600, Kurt Seifried wrote:
And don't believe in "automated security". I feel quite strong about that automatic updates won't work without heavy human supervision. :) Having your system (potentially) damaged by a simple minded program sucking in every update unchecked just because "the file was there and I felt like applying it" is not fun. When something breaks, *I* want to be the reason why. :>
Security has to be automated as much as possible. What happens when companies roll out 5000 linux desktops?
I guess I put it into the wrong words ...
I meant that I don't believe in automatic upgrading from an external source. I want to be the instance making the decision about how and most of all _when_ to break a system (or to risk breaking it) by updating.
Admittedly I've never been in the above position to handle a few thousands of installations. Neither did I get close to this in any way. :) But I could imagine grouping these machines and applying the updates in steps to see how they react. In a perfect world the updates only remove some remedies and plainly work. In the real world these updates have side effects and you don't want to break *all* machines at _once._ There have been - and always will be - updates which just don't work (quick response in an attempt to help before the "real" fix is found and tested) and updates which change some behaviour other software has to be obeying too.
To put it short: At the very least I would like to to have a filter _which_ updates (of all the availables) get applied and _when_ I want to risk updating my machines. This involves a test beforehand on isolated machines to recognize when a fix for one thing breaks other things or doesn't fix something. I don't believe in a distributor to autodeliver updates to me, I still see this as a service and an offer and I'm still the one to accept or delay or reject.
Of course(?) once I want to apply an update, I'm still free to do so automatically inside my reach, from a source *I* define and for a set of machines I declare (and these could be all machines, as well). We agree that physically stepping up in front of more than ten machines is something no admin would like to do and even doing so via network will raise the feeling "there should be a different way without me sitting here and waiting for the computer(s) to finish". :) And I'm aware that delayed application of available fixes to known problems leave a window of possible vulnerability. But I don't want to be forced to accept fixes' downsides just because a fix is published.
Maybe we're talking about different granularity and release schemes here? Maybe you put more trust into the fix' publisher than I do? But surely I speak as someone who never had to handle more than some twenty machines at once.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
-- The Law of Unintended Consequences: Whether or not what you do has the effet you want, it will have three at least you never expected, and one of those usually unpleasant. Siuan Sanche, Aes Sedai From 'The Path of Daggers', Book Eight of the Wheel of Time Series by Robert Jordan.
On Fri, 11 Aug 2000, Kurt Seifried wrote:
Wrong answer. USE GNUPG. Ok the problem with MD5/SHA1/etc/etc is for each package I need to get you the package, and the sig securely. With GnuPG I need to get the key to you securely ONCE, i.e. SuSE ships the keys on the CD. SuSE cannot ship all the future MD5/SHA1/etc sums on the CD for obvious reasons.
Kurt has is a great answer. It is probably the strongest tool available. By the way seems nearly as secure to md5/SHA1 sign, and then for the signature to be distributed independently signed with a trusted key. That is Roman's signed email announcements. But at the risk of repeating the obvious, I will paraphrase Phil Zimmerman's pgp READMEs: it is only as safe as the computers hosting the signing and checking code. If an attacker trojaned your local GnuPG binary or tampered with your public keyring, he could get false signatures past you. And the trusted suse private key (using suse as an example) may be shared among a number of employees, and it may even be used for automatic code signing (eugh!) It would just take one of them to allow their private keyring to be stolen - and until they notice and get an announcement to you - you are vulnerable to man-in-the-middle attacks. So independent sources may still be a useful weapon in the armory. <SNIP>
fun. When something breaks, *I* want to be the reason why. :>
Security has to be automated as much as possible. What happens when companies roll out 5000 linux desktops?
Quite. And you will be automating firewalls, tripwire, config file distribution and many other weapons. It may make sense to download updates only once (by your admin) manually, verify them and sign them with an in-house key, and then distribute automatically to 5000 workstations. There are other non-security benefits to this. BTW IMHO the key doesn't need to be on the CD to be trusted. The SuSE key fingerprint is in chapter 18 of the manual. If you get a paper manual it is reasonably independent of the Internet. dproc
But at the risk of repeating the obvious, I will paraphrase Phil Zimmerman's pgp READMEs: it is only as safe as the computers hosting the signing and checking code. If an attacker trojaned your local GnuPG binary or tampered with your public keyring, he could get false signatures past you.
This is just as true for the md5sum or sha1 binary on your system! You don't really "lose" anything. If the attacker can replace these binaries that means he has root locally on your system. This also means he can replace your kernel, insert modules, play around with memory, etc, etc. Once an attacker gets root on a system (unless that system is severely secured) the game is over and it is time to reinstall from trusted media. I am much more worried about someone running a mirror site and that site getting compromised (like ftp.win.tue.nl), the attacker trojans the files and md5sums on the remote site, users download and everything appears ok. With GnuPG that would not be possible, the attacker would have to break into the SuSE machine used to sign packages. I assume this machine is NOT online, i.e. they have removable media such as a jaz drive to move the data, meaning any attack would have to be physical (which really reduces the number of people capable of carrying it out).
And the trusted suse private key (using suse as an example) may be shared among a number of employees, and it may even be used for automatic code signing (eugh!) It would just take one of them to allow their private keyring to be stolen - and until they notice and get an announcement to you - you are vulnerable to man-in-the-middle attacks.
"may be shared". And SuSE might install a default root password we can't remove. What the heck is your point? Now you're making things up and talking out your ass. Can we stick to facts instead of making them up?
BTW IMHO the key doesn't need to be on the CD to be trusted. The SuSE key fingerprint is in chapter 18 of the manual. If you get a paper manual it is reasonably independent of the Internet.
GnuPG key disitribution is a *LOT* easier, you only have to do it once, correctly. You can reinforce it by having the key on your website, attached to emails, etc. Doing md5sum/sha1 distribution is an impossible task (you need a seperate secure channel for it, etc, etc).
dproc
-Kurt
On Sat, 12 Aug 2000, Kurt Seifried wrote:
If an attacker trojaned your local GnuPG binary or tampered with your public keyring, he could get false signatures past you.
This is just as true for the md5sum or sha1 binary on your system! You don't really "lose" anything. If the attacker can replace these binaries that means he has root locally on your system. This also means he can replace
Kurt is (almost) right. Although my public keyring is owner user (not root), in theory my user account is just as secure as root. I was wrong.
I am much more worried about someone running a mirror site and that site getting compromised (like ftp.win.tue.nl), the attacker trojans the files and md5sums on the remote site, users download and everything appears ok. With GnuPG that would not be possible,
I agree with Kurt and Volker here. I always did. I am sorry I was not clear. gpg signed distribution would be a *huge step forward*
the attacker would have to break into the SuSE machine used to sign packages. I assume this machine is NOT online, i.e. they have removable media such as a jaz drive to move the data, meaning <SNIP> "may be shared". <SNIP> Can we stick to facts instead of making them up?
I am sure key security at suse and redhat is good. But I know that Roman and Marc and Thomas all sign email announcements with the same security@suse.com private key. I suspect that Red Hat is the same. I expect my guess that they have their own copies was wrong. It is perfectly reasonable that they carry their email on sneakernet to an isolated signing machine, sign it, then copy the signed email back to their networked workstation. Even if their security is weaker than this 'best practice' gpg/pgp signing is still *a good thing*.
BTW IMHO the key doesn't need to be on the CD to be trusted. The SuSE key fingerprint is in chapter 18 of the manual. If you get a paper manual it is reasonably independent of the Internet.
I mean their pgp2 key fingerprint.
GnuPG key disitribution is a *LOT* easier, you only have to do it once,
gpg key distribution is no easier or harder than pgp, is it? It is much easier than md5 fingerprints - which have some technical problems as well as needing the secure channel of suse's pgp-signed announcements. dproc
* dproc wrote on Sun, Aug 13, 2000 at 17:10 -0400:
On Sat, 12 Aug 2000, Kurt Seifried wrote:
the attacker would have to break into the SuSE machine used to sign packages. I assume this machine is NOT online, i.e. they have removable media such as a jaz drive to move the data, meaning <SNIP>
I am sure key security at suse and redhat is good. But I know that Roman and Marc and Thomas all sign email announcements with the same security@suse.com private key. I suspect that Red Hat is the same.
Well, BTW, does anybody knows about the SuSE Signing Policy? I _assume_ they use offline machines in a secured enviroment for any action with their private key, but I don't know. It would be important to know it before it's possible to trust any key.
I expect my guess that they have their own copies was wrong. It is perfectly reasonable that they carry their email on sneakernet to an isolated signing machine, sign it, then copy the signed email back to their networked workstation.
I don't know what the term "sneakernet" exactly means. But if it's some kind of networking connection, it cannot be secure, since it seems to be possible to hack the workstation of such an operator and intrude into this network. If those workstations are behind a firewall, it's possible to break the firewall (or use some trojaner or whatever to get around). Finally, even if they would use unplugged stations for signing in a safe enviroment you have to rely on the integrity on all persons that are authorized to use the private key. The list of all authorized persons may be a long one...
Even if their security is weaker than this 'best practice' gpg/pgp signing is still *a good thing*.
Yep, I think so too. I think getting MD5 sums from a secured source (that is _not_ normal email but i.e. signed mails, https or similar) is as secure as gpg/pgp signing, but not useable in production, this you have to verify the md5 manually on each station you receive this packages by unsecured ways like FTP or NFS (if you want to go for sure), which is impossible. But it's possible to install a key and verifying a fingerprint once for each station. In a network with some 10K hosts it's a different story of course. But usually 95% of those machines have to rely on the integrety on some internal servers (i.e. NFS...) and offer or use local (insecure) services, so it should be possible and neccesary to use some distribution feature. A friend of me had build such a thing, where the workstations can be installed useing a special boot floppy which installs a cpio-archive via nfs and updates config (...) via SSH useing some authorized_keys. Of course there the security depends on the security of the NFS server, but it's a working way... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Just as an FYI: Sneaker net is the process of putting what you want on removable media, walking over to an isolated box, and transferring the data to the non-networked machine. Sneakers - Walking, I'm sure you get the idea. :) Steven Senior Network Nazi -----Original Message----- From: Steffen Dettmer [mailto:steffen@dett.de] Sent: Monday, August 14, 2000 12:43 AM To: suse-security@suse.com Subject: Re: [suse-security] autorpm and latest secure files * dproc wrote on Sun, Aug 13, 2000 at 17:10 -0400:
On Sat, 12 Aug 2000, Kurt Seifried wrote:
the attacker would have to break into the SuSE machine used to sign packages. I assume this machine is NOT online, i.e. they have removable media such as a jaz drive to move the data, meaning <SNIP>
I am sure key security at suse and redhat is good. But I know that Roman and Marc and Thomas all sign email announcements with the same security@suse.com private key. I suspect that Red Hat is the same.
Well, BTW, does anybody knows about the SuSE Signing Policy? I _assume_ they use offline machines in a secured enviroment for any action with their private key, but I don't know. It would be important to know it before it's possible to trust any key.
I expect my guess that they have their own copies was wrong. It is perfectly reasonable that they carry their email on sneakernet to an isolated signing machine, sign it, then copy the signed email back to their networked workstation.
I don't know what the term "sneakernet" exactly means. But if it's some kind of networking connection, it cannot be secure, since it seems to be possible to hack the workstation of such an operator and intrude into this network. If those workstations are behind a firewall, it's possible to break the firewall (or use some trojaner or whatever to get around). Finally, even if they would use unplugged stations for signing in a safe enviroment you have to rely on the integrity on all persons that are authorized to use the private key. The list of all authorized persons may be a long one...
Even if their security is weaker than this 'best practice' gpg/pgp signing is still *a good thing*.
Yep, I think so too. I think getting MD5 sums from a secured source (that is _not_ normal email but i.e. signed mails, https or similar) is as secure as gpg/pgp signing, but not useable in production, this you have to verify the md5 manually on each station you receive this packages by unsecured ways like FTP or NFS (if you want to go for sure), which is impossible. But it's possible to install a key and verifying a fingerprint once for each station. In a network with some 10K hosts it's a different story of course. But usually 95% of those machines have to rely on the integrety on some internal servers (i.e. NFS...) and offer or use local (insecure) services, so it should be possible and neccesary to use some distribution feature. A friend of me had build such a thing, where the workstations can be installed useing a special boot floppy which installs a cpio-archive via nfs and updates config (...) via SSH useing some authorized_keys. Of course there the security depends on the security of the NFS server, but it's a working way... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
I think this qualifies as a security issue because the only other solution I have would be to open up permissions completely and I don't know which I can safely do. I am running SuSE 6.2 and I have Marc's firewall script version 2.5 running. When trying to send mail from pine as a user from the linux machine, I got an "insufficient permission" message which I resolved by chmod 777 /var/spool/mqueue. I now get reminders of this "warning world writable". Trying to send mail from one local user to another still fails. The following entries are generated in /var/log/mail: Aug 11 07:41:23 celebrity procmail[26474]: Insufficient privileges to deliver to "debbie" Aug 11 07:41:23 celebrity sendmail[26473]: HAA26472: to=<debbie@celebrity.grinton.net>, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAA26472: HAA26473: DSN: Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAA26473: to=andrew, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Sent Aug 11 07:41:23 celebrity sendmail[26473]: HAA26472: HAB26473: postmaster notify : Insufficient permission Aug 11 07:41:23 celebrity procmail[26476]: Insufficient privileges to deliver to "root" Aug 11 07:41:23 celebrity sendmail[26473]: HAB26473: to=root, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAB26473: HAC26473: return to sender: Insufficient permission Aug 11 07:41:23 celebrity procmail[26477]: Insufficient privileges to deliver to "root" Aug 11 07:41:23 celebrity sendmail[26473]: HAC26473: to=root, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAB26473: Saved message in /usr/tmp/dead.letter Permissions in /var/spool are: drwxrwxrwt 2 root root 1024 Aug 11 07:43 mail drwxrwxrwx 2 root root 2048 Aug 11 07:41 mqueue
ls -l /usr/sbin/sendmail -r-xr-xr-x 1 root root 383232 Aug 22 1999 /usr/sbin/sendmail
ls -l /usr/bin/procmail -rwxr-xr-x 1 root root 65428 Dec 7 1999 /usr/bin/procmail
Extracts from my sendmail.mc file include(`/usr/share/sendmail/m4/cf.m4') OSTYPE(`linux')dnl define(`STATUS_FILE', `/var/log/sendmail.st')dnl define(`confDEF_USER_ID', `daemon:daemon')dnl define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl define(`confCOPY_ERRORS_TO', `Postmaster')dnl define(`UUCP_MAILER_MAX', `2000000')dnl define(`confTRUSTED_USERS', `mdom wwwrun')dnl define(`MASQUERADE_AS', `grinton.net')dnl FEATURE(`limited_masquerade')dnl FEATURE(`masquerade_entire_domain')dnl FEATURE(`masquerade_envelope')dnl FEATURE(`local_procmail')dnl FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl MAILER(`local')dnl MAILER(`procmail')dnl MAILER(`smtp')dnl MAILER(`uucp')dnl MAILER(`bsmtp')dnl MAILER(`fido')dnl define(`confCW_FILE', `/etc/mail/sendmail.cw')dnl FEATURE(use_cw_file)dnl MASQUERADE_DOMAIN(grinton.net) -- Andrew Hougie, Grinton, Aldenham Grove, Radlett, Hertfordshire, England, WD7 7BW Email: andrew@hougie.co.uk WWW: http://www.hougie.co.uk
I once got this problem too with procmail. I also remeber that that is what I did at first but then of course I realised that it was a dangerous course of action I then made procmail suid root which worked but was equally dangerous. But checking my permissions later I realised that somehow /usr/sbin/sendmail had stopped being suid root and that is why I had been getting those errors. Of course another equally dangerous way but which would work is to make /usr/bin/pine suid root. On Fri, 11 Aug 2000, Andrew Hougie wrote:
Date: Fri, 11 Aug 2000 08:02:06 +0100 From: Andrew Hougie <andrew@hougie.co.uk> To: suse-security@suse.com Subject: [suse-security] Mail permissions for local users?
I think this qualifies as a security issue because the only other solution I have would be to open up permissions completely and I don't know which I can safely do.
I am running SuSE 6.2 and I have Marc's firewall script version 2.5 running.
When trying to send mail from pine as a user from the linux machine, I got an "insufficient permission" message which I resolved by chmod 777 /var/spool/mqueue. I now get reminders of this "warning world writable".
Trying to send mail from one local user to another still fails. The following entries are generated in /var/log/mail:
Aug 11 07:41:23 celebrity procmail[26474]: Insufficient privileges to deliver to "debbie" Aug 11 07:41:23 celebrity sendmail[26473]: HAA26472: to=<debbie@celebrity.grinton.net>, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAA26472: HAA26473: DSN: Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAA26473: to=andrew, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Sent Aug 11 07:41:23 celebrity sendmail[26473]: HAA26472: HAB26473: postmaster notify : Insufficient permission Aug 11 07:41:23 celebrity procmail[26476]: Insufficient privileges to deliver to "root" Aug 11 07:41:23 celebrity sendmail[26473]: HAB26473: to=root, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAB26473: HAC26473: return to sender: Insufficient permission Aug 11 07:41:23 celebrity procmail[26477]: Insufficient privileges to deliver to "root" Aug 11 07:41:23 celebrity sendmail[26473]: HAC26473: to=root, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAB26473: Saved message in /usr/tmp/dead.letter
Permissions in /var/spool are: drwxrwxrwt 2 root root 1024 Aug 11 07:43 mail drwxrwxrwx 2 root root 2048 Aug 11 07:41 mqueue
ls -l /usr/sbin/sendmail -r-xr-xr-x 1 root root 383232 Aug 22 1999 /usr/sbin/sendmail
ls -l /usr/bin/procmail -rwxr-xr-x 1 root root 65428 Dec 7 1999 /usr/bin/procmail
Extracts from my sendmail.mc file include(`/usr/share/sendmail/m4/cf.m4') OSTYPE(`linux')dnl define(`STATUS_FILE', `/var/log/sendmail.st')dnl define(`confDEF_USER_ID', `daemon:daemon')dnl define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl define(`confCOPY_ERRORS_TO', `Postmaster')dnl define(`UUCP_MAILER_MAX', `2000000')dnl define(`confTRUSTED_USERS', `mdom wwwrun')dnl define(`MASQUERADE_AS', `grinton.net')dnl FEATURE(`limited_masquerade')dnl FEATURE(`masquerade_entire_domain')dnl FEATURE(`masquerade_envelope')dnl FEATURE(`local_procmail')dnl FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl MAILER(`local')dnl MAILER(`procmail')dnl MAILER(`smtp')dnl MAILER(`uucp')dnl MAILER(`bsmtp')dnl MAILER(`fido')dnl define(`confCW_FILE', `/etc/mail/sendmail.cw')dnl FEATURE(use_cw_file)dnl MASQUERADE_DOMAIN(grinton.net)
-- Andrew Hougie, Grinton, Aldenham Grove, Radlett, Hertfordshire, England, WD7 7BW Email: andrew@hougie.co.uk WWW: http://www.hougie.co.uk
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Noah ksemat@eahd.or.ug
On Fri, Aug 11, 2000 at 08:02 +0100, Andrew Hougie wrote:
I think this qualifies as a security issue because the only other solution I have would be to open up permissions completely and I don't know which I can safely do.
I am running SuSE 6.2 and I have Marc's firewall script version 2.5 running.
When trying to send mail from pine as a user from the linux machine, I got an "insufficient permission" message which I resolved by chmod 777 /var/spool/mqueue. I now get reminders of this "warning world writable".
[...] Do you use AMAVIS as Virus checker? The problem occurs with sendmail+amavis, for amavis changes the permissions procmail is started with. There is a patch available at the amavis homepage, bug shall be fixed in next release. Greetings Volker -- The main failure in computers is usually between keyboard and chair. (unknown) Volker Tanner <VolkerTanner@kade.de>
On Fri, 11 Aug 2000, Volker Tanner wrote:
On Fri, Aug 11, 2000 at 08:02 +0100, Andrew Hougie wrote:
When trying to send mail from pine as a user from the linux machine, I got an "insufficient permission" message which I resolved by chmod 777 /var/spool/mqueue. I now get reminders of this "warning world writable".
[...] Do you use AMAVIS as Virus checker? The problem occurs with sendmail+amavis, for amavis changes the permissions procmail is started with. There is a patch available at the amavis homepage, bug shall be fixed in next release.
Uh? It seems that you know more than I do :) Anyway, I wouldn't call it a bug in AMaViS, although we describe this in the file BUGS. Here's the snippet from it ... * depending on your system, subprocess is run as the UID of the local receipient (not 'root'). Calling your local delivery program (usually procmail) then might have insufficient privileges to deliver it any further. FIX: set an "o"-flag in /etc/sendmail.cf Mlocal, P=/usr/sbin/scanmails, F=olsDFMAw5:/|@SPfhn, S=10/30, R=20/40, T=DNS/RFC822/X-Unix, A=scanmails -Y -a $h -d $u Hint: This usually happens on SuSE Linux >=6.0 Hint: If this still does not work, *remove* the "S" flag, too! The Mlocal entry on my system looks like this: Mlocal, P=/usr/sbin/scanmails, F=olsDFMAw5:/|@qPfhn9, S=10/30, R=20/40 T=DNS/RFC822/X-Unix, A=scanmails -Y -a $h -d $u Note: "root" must be in alias to an user account otherwise you will still get the error message Insufficent privileges to deliver to "root". The last Mlocal entry is from my system :) (well, I use the --enable-relay stuff, of course, which does not "interfere" with procmail any more, as a different approach is used and which can scan incoming or relayed mail, too). Btw, we run three public mailing lists for AMaViS (http://sourceforge.net/mail/?group_id=6006). So please use them instead of posting AMaViS problems in suse-security. Thanks. HTH best regards, Rainer Link -- Rainer Link, SuSE GmbH, eMail: link@suse.de, Web: www.suse.de Developer of A Mail Virus Scanner (AMaViS): http://amavis.org/ Founder of Linux AntiVirus Project: http://lavp.sourceforge.net/
On Fri, Aug 11, 2000 at 11:26 +0200, Rainer Link wrote:
On Fri, 11 Aug 2000, Volker Tanner wrote:
[...]
[...] Do you use AMAVIS as Virus checker? The problem occurs with sendmail+amavis, for amavis changes the permissions procmail is started with. There is a patch available at the amavis homepage, bug shall be fixed in next release.
Uh? It seems that you know more than I do :)
OK, I forgot the appendix. echo ", I have heard, I forgot from whom" >> $my_first_paragraph Greetings Volker -- The main failure in computers is usually between keyboard and chair. (unknown) Volker Tanner <VolkerTanner@kade.de>
Your sendmail has permissions 555. It should be suid root (4555). That will clear up the problem. Then make mqueue 700, mail should be sticky, since it's world writeable (mode 1777). BTW: if you're running a kernel prior to 2.2.16 this does leave you open to attacks, since older kernels have a bug. See the SuSE security announcements. Hope this helps Stefan On Fri, 11 Aug 2000, Andrew Hougie wrote:
I think this qualifies as a security issue because the only other solution I have would be to open up permissions completely and I don't know which I can safely do.
I am running SuSE 6.2 and I have Marc's firewall script version 2.5 running.
When trying to send mail from pine as a user from the linux machine, I got an "insufficient permission" message which I resolved by chmod 777 /var/spool/mqueue. I now get reminders of this "warning world writable".
Trying to send mail from one local user to another still fails. The following entries are generated in /var/log/mail:
Aug 11 07:41:23 celebrity procmail[26474]: Insufficient privileges to deliver to "debbie" Aug 11 07:41:23 celebrity sendmail[26473]: HAA26472: to=<debbie@celebrity.grinton.net>, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAA26472: HAA26473: DSN: Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAA26473: to=andrew, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Sent Aug 11 07:41:23 celebrity sendmail[26473]: HAA26472: HAB26473: postmaster notify : Insufficient permission Aug 11 07:41:23 celebrity procmail[26476]: Insufficient privileges to deliver to "root" Aug 11 07:41:23 celebrity sendmail[26473]: HAB26473: to=root, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAB26473: HAC26473: return to sender: Insufficient permission Aug 11 07:41:23 celebrity procmail[26477]: Insufficient privileges to deliver to "root" Aug 11 07:41:23 celebrity sendmail[26473]: HAC26473: to=root, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAB26473: Saved message in /usr/tmp/dead.letter
Permissions in /var/spool are: drwxrwxrwt 2 root root 1024 Aug 11 07:43 mail drwxrwxrwx 2 root root 2048 Aug 11 07:41 mqueue
ls -l /usr/sbin/sendmail -r-xr-xr-x 1 root root 383232 Aug 22 1999 /usr/sbin/sendmail
ls -l /usr/bin/procmail -rwxr-xr-x 1 root root 65428 Dec 7 1999 /usr/bin/procmail
Extracts from my sendmail.mc file include(`/usr/share/sendmail/m4/cf.m4') OSTYPE(`linux')dnl define(`STATUS_FILE', `/var/log/sendmail.st')dnl define(`confDEF_USER_ID', `daemon:daemon')dnl define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl define(`confCOPY_ERRORS_TO', `Postmaster')dnl define(`UUCP_MAILER_MAX', `2000000')dnl define(`confTRUSTED_USERS', `mdom wwwrun')dnl define(`MASQUERADE_AS', `grinton.net')dnl FEATURE(`limited_masquerade')dnl FEATURE(`masquerade_entire_domain')dnl FEATURE(`masquerade_envelope')dnl FEATURE(`local_procmail')dnl FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl MAILER(`local')dnl MAILER(`procmail')dnl MAILER(`smtp')dnl MAILER(`uucp')dnl MAILER(`bsmtp')dnl MAILER(`fido')dnl define(`confCW_FILE', `/etc/mail/sendmail.cw')dnl FEATURE(use_cw_file)dnl MASQUERADE_DOMAIN(grinton.net)
-- Andrew Hougie, Grinton, Aldenham Grove, Radlett, Hertfordshire, England, WD7 7BW Email: andrew@hougie.co.uk WWW: http://www.hougie.co.uk
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
========================================== Stefan Suurmeijer Network Specialist University of Groningen tel: (+31) 50 363 3423 fax: (+31) 50 363 7272 E-mail (business): s.m.suurmeijer@let.rug.nl E-mail (private): stefan@symbolica.nl ========================================== Quis custodiet ipsos custodes? (Who'll watch the watchmen?) - Unknown
Thank you. That worked Andrew On Fri, 11 Aug 2000, Stefan Suurmeijer wrote:
Your sendmail has permissions 555. It should be suid root (4555). That will clear up the problem. Then make mqueue 700, mail should be sticky, since it's world writeable (mode 1777).
BTW: if you're running a kernel prior to 2.2.16 this does leave you open to attacks, since older kernels have a bug. See the SuSE security announcements.
Hope this helps
Stefan
On Fri, 11 Aug 2000, Andrew Hougie wrote:
I think this qualifies as a security issue because the only other solution I have would be to open up permissions completely and I don't know which I can safely do.
I am running SuSE 6.2 and I have Marc's firewall script version 2.5 running.
When trying to send mail from pine as a user from the linux machine, I got an "insufficient permission" message which I resolved by chmod 777 /var/spool/mqueue. I now get reminders of this "warning world writable".
Trying to send mail from one local user to another still fails. The following entries are generated in /var/log/mail:
Aug 11 07:41:23 celebrity procmail[26474]: Insufficient privileges to deliver to "debbie" Aug 11 07:41:23 celebrity sendmail[26473]: HAA26472: to=<debbie@celebrity.grinton.net>, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAA26472: HAA26473: DSN: Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAA26473: to=andrew, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Sent Aug 11 07:41:23 celebrity sendmail[26473]: HAA26472: HAB26473: postmaster notify : Insufficient permission Aug 11 07:41:23 celebrity procmail[26476]: Insufficient privileges to deliver to "root" Aug 11 07:41:23 celebrity sendmail[26473]: HAB26473: to=root, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAB26473: HAC26473: return to sender: Insufficient permission Aug 11 07:41:23 celebrity procmail[26477]: Insufficient privileges to deliver to "root" Aug 11 07:41:23 celebrity sendmail[26473]: HAC26473: to=root, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Insufficient permission Aug 11 07:41:23 celebrity sendmail[26473]: HAB26473: Saved message in /usr/tmp/dead.letter
Permissions in /var/spool are: drwxrwxrwt 2 root root 1024 Aug 11 07:43 mail drwxrwxrwx 2 root root 2048 Aug 11 07:41 mqueue
ls -l /usr/sbin/sendmail -r-xr-xr-x 1 root root 383232 Aug 22 1999 /usr/sbin/sendmail
ls -l /usr/bin/procmail -rwxr-xr-x 1 root root 65428 Dec 7 1999 /usr/bin/procmail
Extracts from my sendmail.mc file include(`/usr/share/sendmail/m4/cf.m4') OSTYPE(`linux')dnl define(`STATUS_FILE', `/var/log/sendmail.st')dnl define(`confDEF_USER_ID', `daemon:daemon')dnl define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl define(`confCOPY_ERRORS_TO', `Postmaster')dnl define(`UUCP_MAILER_MAX', `2000000')dnl define(`confTRUSTED_USERS', `mdom wwwrun')dnl define(`MASQUERADE_AS', `grinton.net')dnl FEATURE(`limited_masquerade')dnl FEATURE(`masquerade_entire_domain')dnl FEATURE(`masquerade_envelope')dnl FEATURE(`local_procmail')dnl FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl MAILER(`local')dnl MAILER(`procmail')dnl MAILER(`smtp')dnl MAILER(`uucp')dnl MAILER(`bsmtp')dnl MAILER(`fido')dnl define(`confCW_FILE', `/etc/mail/sendmail.cw')dnl FEATURE(use_cw_file)dnl MASQUERADE_DOMAIN(grinton.net)
-- Andrew Hougie, Grinton, Aldenham Grove, Radlett, Hertfordshire, England, WD7 7BW Email: andrew@hougie.co.uk WWW: http://www.hougie.co.uk
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
========================================== Stefan Suurmeijer Network Specialist University of Groningen tel: (+31) 50 363 3423 fax: (+31) 50 363 7272 E-mail (business): s.m.suurmeijer@let.rug.nl E-mail (private): stefan@symbolica.nl ==========================================
Quis custodiet ipsos custodes? (Who'll watch the watchmen?) - Unknown
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
participants (15)
-
Andrew Hougie -
dproc -
Gerhard Sittig -
ksemat＠wawa.eahd.or.ug -
Kurt Seifried -
Magus Ba'al -
Monte Milanuk -
Oliver Grube -
Rainer Link -
Roman Drahtmueller -
Stefan Suurmeijer -
Steffen Dettmer -
Thomas Forbriger -
Volker Kuhlmann -
Volker Tanner