SCIENTIFIC-LINUX-USERS Archives

June 2011

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Yasha Karant <[log in to unmask]>
Reply To:
Yasha Karant <[log in to unmask]>
Date:
Tue, 28 Jun 2011 07:06:06 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (153 lines)
The issue of the intellectual property license is very real; I believe 
that a fundamental difference between the BSD license and many of the 
other "free" licenses that operate using Linux and/or the GPL is the 
strict ability to commercialize for profit a BSD licensed product. 
However, I do not think all of the utilities upon which the iRedMail 
product is based exclusively are BSD, and thus iRedMail may have some 
issues, even with a "public domain" implementation.

Unfortunately, the GPG and related authentication methods are not fully 
resistant to compromise; a primary server or a mirror could be 
compromised with a false signature as well as checksums for the 
compromised system, one could face a man-in-the-middle compromise again 
substituting correct but compromised authentication systems for 
compromised data/source code/information, or other compromises are possible.

A more trustworthy, but still not compromise proof method, is to 
distribute physical media by traceable courier -- this method works 
unless the attacker is extremely determined (e.g., the 
intelligence/disinformation/cyber-warfare services of a nation-state or 
equivalent) or the recipient is extremely naive (e.g., using media from 
an origin in a nation-state known to be lax about matters of fraud or 
media the origin of which cannot be traced).

However, as pointed out by Kadel-Garcia, the iRedMail distribution 
authentication method is very prone to compromise, even from the source.

Yasha Karant

On 06/28/2011 06:24 AM, Nico Kadel-Garcia wrote:
> On Tue, Jun 28, 2011 at 3:08 AM, Zhang Huangbin
> <[log in to unmask]>  wrote:
>>
>> On Jun 28, 2011, at 1:41 PM, Nico Kadel-Garcia wrote:
>>
>>> On Tue, Jun 28, 2011 at 12:10 AM, Zhang Huangbin
>>> <[log in to unmask]>  wrote:
>>>> Dear Scientific Linux users,
>>>>
>>>> Just want to let you know, there's a free and open source mail server
>>>> solution, iRedMail, works well on Scientific Linux 5.x, supports both
>>>> i386 and x86_64. Web site: http://www.iredmail.org/
>>>
>>> And Postfix.
>>>
>>> And Sendmail.
>>>
>>> And Exim.
>>>
>>> And Qmail.
>>>
>>> And look,  it's available only as an installer which reaches out and
>>> downloads things from your website without actually mentioning what
>>> they are in advance. Wow, I could go on with the obvious issues from
>>> the website, but given that there's not even a GPG signature for the
>>> installation widget, this is actively unsafe.
>>
>>
>> Sorry about unclear description.
>
> That is, perhaps, the *least* of the problems. Downloading unsigned
> binary packages from a third-party for a production system like email
> services is begging for trouble. All we need is your domain hijacked,
> and your clients will be installing rootkits without your or their
> awareness.
>
>> iRedMail is just shell scripts, it will install and configure mail server
>> related components automatically for you. That's why i call it a 'solution'
>> instead of a 'software'. Source code of iRedMail is available in Google
>> Code: http://code.google.com/p/iredmail/source/list
>
> And the *source* should be published
>
>> Used major components:
>>
>> - Postfix (SMTP)
>> - Dovecot (POP3, IMAP, Managesieve)
>> - Apache (Web server)
>> - MySQL (Storing application data and/or mail accounts)
>> - OpenLDAP (Storing mail accounts)
>> - Amavisd + SpamAssassin + ClamAV (anti-spam, anti-virus)
>> - Roundcube (Webmail)
>> - Awstats (Apache and Postfix log analyzer)
>
> Good. Now put that on your web page, please.
>
>> Since RHEL doesn't provide all of them, iRedMail project has to provide
>> some of them. As we mentioned in README[1] file under yum repository
>> directory, most of them comes from third-party repositories, some were
>> packed by iRedMail project, SRPMS are avalable:
>
> See above. It should really be in the web page, *long* before setting
> up yum repositories.
>
>> ####
>> Most packages come from:
>>
>>     - Dag Wieers: http://packages.sw.be/
>>     - EPEL: http://download.fedora.redhat.com/pub/epel/
>>     - ATrpms.net: http://atrpms.net/
>>
>> Thank you all :)
>>
>> Packages which contains 'ired' tag in package name are packed
>> by iRedMail project, you can find source RPM here:
>> http://iredmail.org/yum/srpms/
>> ####
>
> Which should be..... wait for it...... on the web page. I also note
> that the packages there lack GPG signatures.
>
> Worse is your listing for 'License' under your SRPM's. "Public Domain
> and BSD" is not a license. It's a legal morass, begging for a client
> to step in it and lose a boot. Pick one!!!!!
>
>> iRedMail will verify packages with command 'md5sum'[2] after downloaded
>> to make sure they're truly downloaded from iredmail.org.
>
> Which is not the same as a GPG signature. That's merely a transmission
> verification, not a sign that the original package actually came from
> anyone you trust. The lack of a checksum for the installer tarball is,
> in particularly, hazardous, since a malicious person could replace the
> contents of *that*.
>
> Security takes attention. This lack of attention to basic security
> steps is frightening in a tool that expects to integrate numerous,
> password handling components such as jabber, Postfix, Dovecot, and
> MySQL.
>
>> [1] README: http://iredmail.org/yum/rpms/5/00README
>> [2] Verify packages with 'md5sum': it's defined in some files:
>>     o iRedMail-x.y.z/pkgs/get_all.sh
>>     o iRedMail-x.y.z/pkgs/MD5.*
>
> And nothing in the srpms or source directories. Defining checksums
> inside  the already downloaded installer for 3rd-party downloads is
> missing the point, and does nothing to alleviate concerns abou the
> authenticity of the package, especially if an RPM is built and
> replaced by a malicious third party from their own, unpublished SRPM.
> It's very important for security to tie the binary RPM's to the source
> RPM's from the same author. This is pretty basic security practice for
> software repositories. Can I, or someone else, find you a guideline on
> this?
>
> Even if I distruct your product outright due to these missing
> features, I'm happy for people to learn how to do these security
> practices better.
>
>> ----
>> Zhang Huangbin
>>
>> iRedMail: Open Source Mail Server Solution for Red Hat Enterprise Linux,
>> CentOS, Debian, Ubuntu, openSUSE, FreeBSD: http://www.iredmail.org/

ATOM RSS1 RSS2