[Mageia-dev] [RFC] msec (nail) can't send reports to local users accounts - require an MTA?

Fri Sep 23 11:05:03 CEST 2011

Am 23.09.2011 10:47, schrieb Florian Hubold:
+> Am 22.09.2011 23:11, schrieb andre999:
+>> Florian Hubold a écrit :
+>>> Am 22.09.2011 00:09, schrieb Luc Menut:
+>>>> Le 21/09/2011 20:35, Florian Hubold a écrit :
+>>>>> Hello,
+>>>>>
+>>>>> during validation of validation of msec/sectool update candidates,
+>>>>> a problem showed up: https://bugs.mageia.org/show_bug.cgi?id=1621
+>>>> ...
+>>>>> But if we want security reports to be sent to local users if they
+>>>>> specify so, how to proceed further?
+>>>>
+>>>> msec can work very well without sending these reports by email; all
+>>>> the security's reports are available in /var/log/security, and msec
+>>>> notifies the user about this at each time it runs, so sendmail is
+>>>> absolutely not mandatory.
+>>>> So I think that msec shouldn't have a Requires on sendmail-command,
+>>>> eventually it can be a Suggest.
+>>>>
+>>>> But perhaps we could/should change the configuration of msec to not
+>>>> send email by default, by adding MAIL_WARN=no in
+>>>> /etc/security/msec/security.conf.
+>>>>
+>>> So, to summarize, there happen to be multiple solutions here:
+>>>
+>>> 1. do NOT require an MTA, let users manually read reports from
+>>> /var/log/security
+>>> maybe even remove nail from msec Requires as it is currently
+>>> non-functional.
+>>
+>> Reading from /var/log/security is not especially user-friendly, and will be 
+>> ignored by less savy users.
+> Less savvy users might also not want to read security reports, also it would 
+> mean they
+> can't interpret them properly or fix the cause of reported problems, no?
+>>
+>>> Also Luc's proposal cited above could be realized.
+>>
+>> see below.
+>>
+>>> 2. do require sendmail-command, which will pose a problem to users
+>>> installing from the CLI, because they are presented with a choice:
+>>>
+>>> One of the following packages is required:
+>>> 1 dma
+>>> 2 ssmtp
+>>> 3 postfix
+>>> 4 sendmail
+>>> 5 msmtp
+>>> Please make a selection:
+>>>
+>>> Additionally this will force an MTA onto every default installation and
+>>> every
+>>> installation that currently has msec installed.
+>>
+>> Solution 3 avoids the complication of choosing, with virtually no disadvantage.
+>>
+>>> 3. do require dma, which is a rather minimal MTA, and delivers without
+>>> configuration
+>>> Please see https://bugs.mageia.org/show_bug.cgi?id=2255#c36 for details.
+>>> This would also allow coexistence with an already-installed MTA, IIUC.
+>>
+>> (dragonfly mail agent)
+>> If this works, I'd say that it is the best solution, since it is very 
+>> compact (64k), and virtually every system will have the DNS it requires 
+>> installed.
+>> (Unless of course they don't have Internet or network access.  In which case 
+>> msec would not be particularly important.)
+>> Note that it is only at version 0.2 (or 0.3 upstream), so we should test it 
+>> carefully.
+>>
+>>> 4. Try to fix nail, which is required by msec and so in every default
+>>> installation,
+>>> so that it is able to deliver mail by itself, without sendmail.
+>>
+>> Solution #3 seems much better in every respect.
+>>
+>>> Please give your votes.
+>>
+>> Solution 3, with changes/verifications noted below.
+>> Since it is much simpler for the end-user to always have the capability to 
+>> send security alerts if an email address is entered, without installing 
+>> anything extra.
+>>
+>> There are 2 options at the bottom of the first security page of msec, which 
+>> should already realise Luc's proposals.  They may have to be fixed.
+>>
+>> a) An option to send a security alert by email, where one enters the email 
+>> address.  By default it is checked.
+>> However, if no valid format email address is entered, an email should _not_ 
+>> be sent.
+>> As well, we should display something similar to
+>> "(Enter {userid}@localhost for a local user.)",
+>>  to help ensure that the user enters a valid local address.
+>> (Note that there are multi-line descriptions for all the other options above 
+>> on the same page, so this would fit nicely.)
+>>
+>> b) An option to display security alerts on the desktop.  Again, checked by 
+>> default.  They should probably remain visible until the user dismisses them. 
+>> (They currently display for a few seconds, then disappear.)
+Correction: If you mean a notification popup which tells you that the report 
+can be looked
+up at /path/to/report is already in place, aus Eugeni told already.
+>>
+>> My 2 cents :)
+>>
+> Feel free to send patches for a) and b).
+>
+
+