Le lundi 10 janvier 2011, Sylvain Beucler a écrit : > chkrootkit has been triggering a lot of false positive (like SQL > injection monitor ;)). In addition it can only be run securely on a > trusted box, because an attacker installing a rootkit can patch or > disable chkrootkit on a compromised system. I don't remember if it > was installed at Gna! but we didn't keep it at Savannah for these > reasons. > > (Jame Villate found the Savannah rootkit in 2003 btw, not Vincent, but > that's an old story now)
I don't remember exactly but I'm quite sure Vincent was at least responsible for installing chkrootkit. (I'm sure, anyway, Jaime know I don't mean to underestimate it's involvement; it's no secret, for instance, that without him, there would have been no CERN contribution at all) I'm not saying chkrootkit is the ultimate answer. I'm just saying I'm finding it very hard to track down current security measures while there were plenty of little ones (no ultimate weapon, though, that's correct) at start that diseappear with no obvious replacement. For instance, is there any files integrity checks done? > /root/TODO is basically my personal roadmap when I was working mostly > alone on upgrading the infra. I didn't think much about it but it was > more convenient to use than a dozen of separate tracker items in that > particular case. We use trackers for a number of things but we also > know when not to use them. All projects I know of make use of trackers not because it is fast. There is an obvious overhead. But the point is to communicate and allow other to keep tracks about what is going on. The very idea of "personal roadmap" is quite annoying. Even if I understand well how it is practical. > /root/.ssh/authorized_keys is managed automatically in the host > (Bearstech procedure). The guests are managed manually because nobody > took the time to install the script. Note that the script does not > automate the task for security reasons, instead it suggests what keys > to add. Mixing Savane users and system users doesn't sound good, so > better leave the backup key as-is. How does it not sound good? As you stated, there is no security issue about it. So it is because nobody took the time to install it or is it because it is not a so good idea? You brought up the perfect example of what I'm trying to talk about: Everything looks that way, things that were are goner but there's no clear explanation: maybe it is a matter of time; but maybe it is because one (or more) thought it not so great. So, when you take a look once in a while, you notice something no longer exists, what are you supposed to do? Take the time to fix it? Assuming that it's gone for good reasons? You send a mail each time, bothering people about their choices? Frankly, first reaction is to move on and do something else, elsewhere. All over, it is the same thing. You have to second-guess everything. Or to bother people asking them to justify whether there is a good reason for some removal or if it just because they lack time, while at the same time you devote no time at all. It's just annoying. > Your last remark shows you're aware of the tone of your mail :/ It's not a matter of tone. I cannot think of a nice way to tell people that we think things should be done differently, especially when you are not doing anything at all. And, anyway, by nature, mails are harsh, even if you put smileys everywhere. I thought useful to say that I'm not questioning what is done. From what I see, it is very good. I'm just talking about what is not done and how I do not think it can be addressed in the current state of thing. Unwritten policies, unexplained choices, I dont see how it can work if we want more than one person in charge at a time. -- Mathieu Roy
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Project mailing list [email protected] https://mail.gna.org/listinfo/project
