[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse
Subject:    Re: [opensuse] Re: Why are systemd's logs stored as binaries?
From:       John Andersen <jsamyth () gmail ! com>
Date:       2016-12-23 22:05:41
Message-ID: 6485dd8b-df15-e34a-5e57-2e95257cdc06 () gmail ! com
[Download RAW message or body]

On 12/23/2016 01:46 PM, Greg Freemyer wrote:
> On Fri, Dec 23, 2016 at 3:40 PM, John Andersen <jsamyth@gmail.com> wrote:
>> Old logs are already compressed routinely, and decompressing them and printing
>> them out has nevee cause a judge or Magistrate to toss them out of court.
>> Find me ONE case law example of this happening in any jurisdiction in the world!!!
> 
> 
> John,
> 
> I do this for a living. For records of any kind to be used in court,
> someone has to provide a foundation as to why the records are accurate
> and trustworthy.  Logs are no different.  The court starts with the
> assumption that all potential evidence is unreliable.  That's why all
> records introduced in court have to be introduced by someone who can
> provide a foundation as to their reliability.
> 
> 5 examples:
> 
> 1) Once I was asked to certify phone billing logs for a client.  They
> gave me a print-out of the billing records they wanted certified.
> 
> I refused and said I could only certify the billing records if I got
> them straight from the original source (the phone company website) and
> printed them myself.
> 
> When I did, there were key changes.  My client had downloaded the text
> billing logs and edited them to get rid of the evidence, then wanted
> me to swear they were reliable.  If I'd have done so, I'd need to find
> a new career.
> 
> 2) In a UNIX (pre-linux) work environment I once had to evaluate who
> had conducted certain actions.  The logs showed it was person A.  We
> didn't trust those text logs and reviewed the shell history files for
> all the users to see if we could find any contradictory evidence.  We
> found where an admin (root level user) had used vi to edit the
> relevant log files shortly after the key event took place.
> 
> If he would have edited his own shell history file, we would have
> never known.  Just goes to show how untrustworthy text logs can be.
> 
> 3) Modern malware is known to attempt to cover its tracks.  It first
> gets root/admin privileges, then does its dirty work, then attempts
> delete the relevant logs.  With text logs, that can be very targeted.
> With Windows binary event logs, it has to delete the entire event log
> file.
> 
> I for one would be unwilling in general to swear text logs are
> reliable.  I would merely be willing to swear the logs being presented
> represented the logs as preserved by me on a given date and time.
> 
> 4) There was a bankruptcy case about 5 years ago where American
> Express was trying to recover a lot of money that had been charged on
> their cards (millions of $s as I recall).  The party going bankrupt
> argued that AmEx'es bills were not a reliable source of information
> about what charges were made to the card.
> 
> I'm sure American Express could have satisfied the court as to why
> their bills were reliable and that the charges they reflected were
> actually made.  Instead AmEx sent a non-technical representative to
> testify to the court about why the billing records were reliable.
> 
> The judge refused to listen to the non-technically knowledgeable
> testimony.  He told American Express they had to produce a person
> knowledgeable about their computer systems and architecture to explain
> how the charges were collected and managed and why they should be
> considered reliable.
> 
> American Express made 2 additional attempts to send someone to certify
> those billing records as reliable.  In both cases the judge refused to
> accept their testimony due to their lack of foundation about how the
> process worked.
> 
> The billing records were therefore not allowed into evidence and AmEx
> recovered none of their money.
> 
> fyi: This was a famous case at the time.
> 
> 5) I worked for the defense in a criminal case where the financial
> records being used by the FBI came out of an accounting system.  The
> records clearly showed that financial filings for grants had false
> information in them.
> 
> As part of my work, I reviewed years of trouble tickets and system
> engineers notes about the specific system in question.  It was clear
> the system had been extremely poorly maintained and the records
> couldn't be trusted.
> 
> ===
> The reality is all evidence used in court has to sworn to as being
> accurate and what their foundation is for swearing to that..  The
> opposing side is allowed to argue that documents aren't reliable and .
> 
>  text logs are not going to be considered reliable in a lot of court
> cases.  I'd be more than happy to be hired to argue about having them
> thrown out of court.
> 
> Greg
> --
> Greg Freemyer
> 

None of that is at question here.

What is at question is that carlos is arguing that the simple
act of dumping a binary log to a text one renders it unacceptable.

I think he is also arguing (unstated) that passing logs through journald
on their way to oldschool syslog also renders them unacceptable by mere extension
of the above.

Of course there is no way for a HUMAN to read the binary logs, so the case
he is building is that journald is basically unusable, because even
the act of reading with journalctl renders the binary log to text.

At that point I am lost as to what he would prefer and what he would trust,
and where is train of though is going.

No, the argument is not that log tampering is impossible, but rather the
concept that rendering logs to text suddenly and by itself renders them
no longer authoritative.

The binary logs are certainly closer to something that is far more tamper
proof.  The format and structure is documented, and will be as readable in
2020 or 2120 as they are today.  But if you don't trust the process of printing
them in human readable form then all is for naught.

Again, the thread has devolved into something begging to be put out of
its own misery.







-- 
After all is said and done, more is said than done.

-- 
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse+owner@opensuse.org

[prev in list] [next in list] [prev in thread] [next in thread]