Re: Challenge to you: Voice your concerns regarding systemd upstream
On 27/09/14 12:31, green wrote:
> green wrote at 2014-09-26 21:04 -0500:
>> Ric Moore wrote at 2014-09-26 18:08 -0500:
>>> On 09/26/2014 05:08 PM, green wrote:
>>>> So, all other things being equal, binary logs are more secure than
>>>> plain text logs. Is that actually what you are saying?
>>>
>>> Yes. The benefit of using a binary log is the lesser vulnerability to an
>>> external attack from an intruder.
<gently>
No - it is not.
</gently>
Good security is based on the "assumption" that you are defending
against a skilled and knowledgeable attacker. Bad security "presumes"
the unknown, and can thus be certain the attacker is stupid and unskilled.
Script kiddie attacks 'might' be the most common, which is probably why
stupid security "policies" are designed to deal with the best case
scenario rather than the worst case. Secure against intelligent attacks
and you'll find you don't need to worry about attacks by idiots.
>>> That huge security flaw was mentioned on a
>>> recent PBS video regarding the new day Hackers and how simply they
>>> removed/edited text-log files to hide their tracks of what they did.
>>
>> So now the attacker just destroys all the logs instead, because it is
>> easier than editing the binary.
And then you *know* your system has been compromised. Which is a very
poor substitute for proper security where your system is designed to:-
;detect intrusions (e.g. SNORT and other NIDS*1)
;limit the extent of successful intrusions (e.g. SELinux)
;detect file alterations (e.g. tripwire and other HIDS*2)
;detect application intrusions (e.g. don't presume all writes to MySQL
are from WordPress - or are legitimate, profile and monitor for
abnormalities. System analysis is good)
...and your OS is kept up to date*4, and the system is constantly
monitored for intrusions while continually being tested to ensure the
security works.
*1 Network Intrusion Detection Systems
*2 Host (-based) Intrusion Detection Systems
*3 Application Protocol (-based) Intrusion Detection Systems
*4 debsecscan
An excellent starting point is to check off the points in:-
https://www.debian.org/doc/manuals/securing-debian-howto/ch10.en.html
(also see the chapter on Debian security tools).
>
> Hm, if you are concerned about the validity of your server logs,
... you're doing it wrong (FTFY) :)
Instead you should rely on system logs only to provide, um, system logs.
System logs != Intrusion Detection Systems (e.g. tripwire)
In the event of intrusion system logs are of limited value as you must
presume they have been tampered with. Useful for forensics but shouldn't
be rely on as a primary means of confirming a successful attack.
> it
> might be prudent to read #10 at
> http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html
>
Expecting enlightenment there 'might' be the triumph of optimism over
experience. It's a *selective* collection of claims from disparate
sources couched in weasel language. e.g.:-
"Unit files GOOD! Shell scripts BAD!"
How about:- Debian's biggest fallacies "Free Software GOOD! Paying for
Software BAD!"
What's wrong with the old tests - see if it floats, if it does drown it
- or burn it at the stake (sigh).
As others have pointed out - the prudent practise is to only deploy that
which has been well tested before deployment. If you're not employing
change control you cannot reasonably expect security. Change control
stops you from deploying Jessie without a compelling argument for not
deploying Wheezy instead (ditto Wheezy vs. Squeeze). Likewise every
single package you install. Do you really need perl *after*
installation? And laptop tools?
Kind regards
Reply to: