msec future and plans
With recent posts by vdanen and adamw, and a recent cooker mailing list thread, it became clear that msec is a very important project/package, and it should deserve much more attention and feedback.
As you probably know, msec underwent a huge redesign for Mandriva 2009.1, and it is getting a lot of attention for 2010.0. But that’s still not enough – even if it became a quite flexible and extensible package, it still has its rough edges, and I intend to solve them all. Of course, it won’t became a perfect package that would rule-them-all, but I intend to get as close to this objective as far as it is humanly possible 
.
So, please, if you use msec, or rsec, or sectool or any other security-concerned framework – please, speak about what you want to see in them, what are the points you are missing, and what features were left unimplemented for the time being.
As for me, I have the following items in the roadmap:
- implement skip list/exceptions for msec, for every possible test, in a similar way to mandriva bug #53307
- do my best to provide a nice common source base for both msec and rsec (I hope vdanen would be interested in that as well). Right now it is possible to configure msec to behave exactly as rsec, doing security checks and nothing besides that, but that is not that trivial to do (well.. it is for me, but not for any casual user out there ), and it should be beneficial to both projects
- provide support for sectool plugins in msec – either directly, or by converting them to msec-parseable format
- work with rsec/sectool/checksecurity/seccheck developers to provide a similar set of features for all those projects. We live in opensource world, and advances in one projects would certainly benefit all of us – specially in such critical area as system security.
So, if you have suggestions, ideas, features or any sort of comments – please, speak. We’ll hear you.
First of all, good job! I think that msec has improved a lot.
Since you say that suggestions are welcome, I would like to request simple things, which are msec related, but I’m unsure if they are beyond msec and more in the Mandriva general structure.
1) Keep the security reports in /var/log/security more than two days. Right now, you have to watch them every single day, which could be annoying in your day off or in your holidays.
2) Not everybody wants an email server in their machine. Is it possible to generate an alert file, and let the user choose where to store it? In addition, it could be included in the logrotate routine.
Bye! motitos
Msec reports each dey the list of files changed on the system, but the check is performed against the original files coming from rpm packages.
Acting in this way, if an cracker change a file that was already changed, msec doesn’t recognize the event.
It would be nice if msec could be improved to cover this case Regards
Hello !
In report, rather than : - Newly installed package : apache-base-2.2.11-10.2mdv2009.11243927306 - No longer present package : apache-base-2.2.11-10.1mdv2009.11242321687
I would like prefer : - Updated package : apache-base (2.2.11-10.2mdv2009 -> 2.2.11-10.1mdv2009)
https://qa.mandriva.com/show_bug.cgi?id=51372
I think that the report should be very clean, perhaps with a summary at the top. Ex: Summary of msec report * 23 world-writable files (+3) * 46 files with wrong permissions (-12) …
Great, thanks for you comments, I’ll try to answer them quickly:
@motitos
– keep security reports for more than two days. Those are kept essentially to compare the results of ‘previous’ run to ‘current’ one. They are called something.’yesterday’ and something.’today’ for historical reasons. But the results of all runs are stored in /var/log/security.log too. For 2010.0, I’ll add a feature which would allow you to view the results for every day.
– saving the results in a file instead of mailing it – it is already done (the results are saved in /var/log/security.log). The only disadvantage is that you must read it by hand. The fix for previous comment would improve this as well.
@Tommaso Massimi:
– comparing files against rpm database. There is a feature in msec which also stored the list of all suid and guid files, comparing their md5 on every run. But you are right, it won’t find ordinary files which were changed by a cracker – msec will just noticed that files were changed. I’ll have to think on something for it.
@Olivier FAURAX:
- msec report formatting. This is something I wanted to do for 2009.1, but had no time. The ‘updated packages’ part is a lot cleaner indeed, I’ll try to implement it shortly.
As for summary part, it is an excellent suggestion, I’ll add it to the TODO list.
Tommaso: don’t use msec for this. Use AIDE. msec can only really do some rudimentary checking and instead of reinventing what Tripwire and AIDE do, you should use them. AIDE works wonders, but you have to keep on top of them. An attacker always has a window of opportunity unless you follow some really basic rules. I.e. run an AIDE report before doing a urpmi/yum upgrade, upgrade the files, then re-run AIDE. Of course, this is still a race condition because AIDE (or any other tool) can’t know that a binary was modified (essentially) twice before the next scan. But you can narrow the window of opportunity quite a bit by doing it that way.
And yeah, Eugene, we need to discuss rsec+msec integration and get something that helps/works with both projects. Then we can dominate sectool and the rest. =)