Re: [DNG] ..forensics on systemd or journald logs

[Clarke Sideroad]

On 25/11/17 11:10 PM, zap wrote:

The troublesome routers I would temporarily try a "factory reset" on

https://www.dd-wrt.com/wiki/index.php/Hard_reset_or_30/30/30
and set them up from scratch and attempt installation of the most
current firmware.

It you are having pop-up warnings I would take a good look at your web
browsers.

Those Netgear routers are old and will probably never be updated by
even third party firmware to cover a host of more modern
vulnerabilities.   I definitely would be fast tracking the phase out
of them if they face the Internet.

I may be wrong, but are not those ADSL gateway/routers, if so that
adds another variable into the selection mix, that may depend greatly
on your ISP's or ISPs' hardware and protocols.

Myself when faced with such situations tend towards selecting a
suitable modem setting it in bridge mode and handling routing with a
dedicated router, this adds more hardware and wall warts, but as
things change maintains better flexibility.
Ubiquity routers are a good choice for routing.


Well, librecmc has worked fine for me as long as I used one with a
graphical built in.

I guess openwrt and ddwrt might not be as good. dunno... I only have
used librecmc. xD


I'm glad that's working for you.
I normally switch consumer grade routers to ddwrt or tomato by Shibby if 
they are supported, I've never tried librecmc, but I'll check it out, 
thanks.


This may have changed since I looked into it, but the supported hardware 
on third party firmware I remember was mostly straight routers or ADSL 
routers with the ADSL part left nonfunctional.


I have to agree with you about factory firmware, it does seem more and 
more is holey by design rather than just error and blatantly phoning 
home for whatever supplied reason.


If a router is "end of life" which may be after only a couple of years 
the chances of getting security patched firmware from the manufacturer 
is zero anyway, even if they admit the insecurity.


Clarke

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs

[zap]

The troublesome routers I would temporarily try a "factory reset" on
> https://www.dd-wrt.com/wiki/index.php/Hard_reset_or_30/30/30
> and set them up from scratch and attempt installation of the most
> current firmware.
>
> It you are having pop-up warnings I would take a good look at your web
> browsers.
>
> Those Netgear routers are old and will probably never be updated by
> even third party firmware to cover a host of more modern
> vulnerabilities.   I definitely would be fast tracking the phase out
> of them if they face the Internet.
>
> I may be wrong, but are not those ADSL gateway/routers, if so that
> adds another variable into the selection mix, that may depend greatly
> on your ISP's or ISPs' hardware and protocols.
>
> Myself when faced with such situations tend towards selecting a
> suitable modem setting it in bridge mode and handling routing with a
> dedicated router, this adds more hardware and wall warts, but as
> things change maintains better flexibility.
> Ubiquity routers are a good choice for routing.
>

Well, librecmc has worked fine for me as long as I used one with a
graphical built in.

I guess openwrt and ddwrt might not be as good. dunno... I only have
used librecmc. xD
> HTH
>
> Clarke
>
>
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs

[Clarke Sideroad]

On 25/11/17 03:23 AM, leloft wrote:

I have learned more about deep-security issues from this list than
  from all other sources combined.  It is probably my most
important resource for informations of this kind: it makes me think in
ways that I would never have even considered, and is as far from
bullshit as it is possible to get for a noob like me who can't 'detect
it'.

  I have recently upgraded the remaining machines at work from Devuan
  Jessie to Ascii. The headless machines are running without issue;
  however the three machines that run X are playing up. It is still
  early days, but since the upgrades, the previously completely stable
  machines keep losing network connectivity.  The router is a Netgear
  DG834 v4, and as I am in the UK, I assume it has the 'backdoor'
  firmware.  The router will not accept a firmware update. All the
  machines here are on allocated addresses 192.168.0.x which have been
  the same for several years without issue. The three machines in
  question are not accepting their allocated addresses (although the
  three headless machines do so every time), one of the machines is using
  more than one address at a time (up to 3 at a time), one of the
  machines displaced a network printer, and yesterday, one machine
  suffered an X 'event' with error messages everywhere referring to all
  sorts of sensitive system files.  The machines will nearly always get
  their allocated addresses after a router reboot followed by a machine
  reboot.  Ugly.

So could I ask for your opinions please?
1) What should I replace the Netgear router with?
  What's the 'critics choice'?
2) Which is less insecure: launching X
  through a display manager (which has root privileges and grants them
  to X), or from startx and Xwrapper with-root-rights=yes and dropping to
  a console when the machine is unattended.
3) What is the current state of play with the new
X-as-a-normal-user in ascii?  How's that shaping up?


The troublesome routers I would temporarily try a "factory reset" on
https://www.dd-wrt.com/wiki/index.php/Hard_reset_or_30/30/30
and set them up from scratch and attempt installation of the most 
current firmware.


It you are having pop-up warnings I would take a good look at your web 
browsers.


Those Netgear routers are old and will probably never be updated by even 
third party firmware to cover a host of more modern vulnerabilities.   I 
definitely would be fast tracking the phase out of them if they face the 
Internet.


I may be wrong, but are not those ADSL gateway/routers, if so that adds 
another variable into the selection mix, that may depend greatly on your 
ISP's or ISPs' hardware and protocols.


Myself when faced with such situations tend towards selecting a suitable 
modem setting it in bridge mode and handling routing with a dedicated 
router, this adds more hardware and wall warts, but as things change 
maintains better flexibility.

Ubiquity routers are a good choice for routing.

HTH

Clarke




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs

[zap]

> So could I ask for your opinions please? 
> 1) What should I replace the Netgear router with?
>  What's the 'critics choice'? 
> 2) Which is less insecure: launching X
>  through a display manager (which has root privileges and grants them
>  to X), or from startx and Xwrapper with-root-rights=yes and dropping to
>  a console when the machine is unattended. 
> 3) What is the current state of play with the new
> X-as-a-normal-user in ascii?  How's that shaping up?
>
> Many Thanks
I personally would use a librecmc router. One of the supported ones I
mean... They require zero blobs and they use zero blobs and moreover,
although they are old, they are secure and librecmc is based off of
LEDE. They even released librecmc 1.41a which resists krack and has
other security fixes based on LEDE ver 17.01 or something

https://gogs.librecmc.org/libreCMC/libreCMC/releases

B*ut, if you do this, make sure you do NOT use a core image or you will
be left without a GUI! I CANNOT STRESS THIS ENOUGH!

*and also, ignore those who say using stock firmware is okay. This
couldn't be further from the truth!

especially with the national spying agency trying to make things so easy
that anyone and their grandma can hack into anything. and before you say
anything remember, *this is an analogy... for how bad things are...

*do some research on librecmc and lede if needed... I currently am using
one.

>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs

[Dan Purgert]

On 11/25/2017 03:23 AM, leloft wrote:
> On Thu, 23 Nov 2017 15:32:52 -0600
> goli...@dyne.org wrote:
> 
> 
> So could I ask for your opinions please? 
> 1) What should I replace the Netgear router with?
>  What's the 'critics choice'? 

If you're a "networking guy" (or at least comfortable with "it's not
plug and pray"), Ubiquiti Edge Routers are top notch IMO.

They've got just enough of a GUI and wizards (once updated to the latest
firmware -- the "as shipped firmware" is pretty spartan) to do most
basic things; but run a fork of Vyatta (6.3, IIRC) on top of Debian
Jessie, so the CLI is quite powerful (and, IMO, easier to navigate than
tomato / ddwrt / etc.)

If you need something that approximates a soho router (1x "WAN" port and
4x "LAN" ports), the ER-X or ER-X-SFP are the ones to get.  Otherwise,
the ER-5-PoE has 2x WAN + 3x LAN (or WAN + LAN1 + LAN2 -- only three
ports are switched). All of the other models are "just routers", and
each port represents a different physical network.


Can't help with the other questions, I don't know enough about X.



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs

[leloft]

On Thu, 23 Nov 2017 15:32:52 -0600
goli...@dyne.org wrote:

> On 2017-11-23 15:06, Rick Moen wrote:
> > 
> > Seriously, guys, less bullshit on security matters, please.  Some
> > of us can actually detect it and find it annoying.
> >   
> 
> What I'm finding annoying is that someone who has been moderated
> still has a presence on this list via a reply to an off-list email.
> 
> golinux

+1

I have learned more about deep-security issues from this list than
 from all other sources combined.  It is probably my most
important resource for informations of this kind: it makes me think in
ways that I would never have even considered, and is as far from
bullshit as it is possible to get for a noob like me who can't 'detect
it'.

 I have recently upgraded the remaining machines at work from Devuan
 Jessie to Ascii. The headless machines are running without issue;
 however the three machines that run X are playing up. It is still
 early days, but since the upgrades, the previously completely stable
 machines keep losing network connectivity.  The router is a Netgear
 DG834 v4, and as I am in the UK, I assume it has the 'backdoor'
 firmware.  The router will not accept a firmware update. All the
 machines here are on allocated addresses 192.168.0.x which have been
 the same for several years without issue. The three machines in
 question are not accepting their allocated addresses (although the
 three headless machines do so every time), one of the machines is using
 more than one address at a time (up to 3 at a time), one of the
 machines displaced a network printer, and yesterday, one machine
 suffered an X 'event' with error messages everywhere referring to all
 sorts of sensitive system files.  The machines will nearly always get
 their allocated addresses after a router reboot followed by a machine
 reboot.  Ugly.

So could I ask for your opinions please? 
1) What should I replace the Netgear router with?
 What's the 'critics choice'? 
2) Which is less insecure: launching X
 through a display manager (which has root privileges and grants them
 to X), or from startx and Xwrapper with-root-rights=yes and dropping to
 a console when the machine is unattended. 
3) What is the current state of play with the new
X-as-a-normal-user in ascii?  How's that shaping up?

Many Thanks



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs

[golinux]

On 2017-11-23 15:06, Rick Moen wrote:


Seriously, guys, less bullshit on security matters, please.  Some of us
can actually detect it and find it annoying.



What I'm finding annoying is that someone who has been moderated still 
has a presence on this list via a reply to an off-list email.


golinux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs

[Rick Moen]

Quoting Arnt Karlsen (a...@iaksess.no):

> On Thu, 23 Nov 2017 14:47:40 +0100, John wrote in message 
> <02372660-5727-d160-fe49-e3a4963f8...@atlantech.com>:
> 
> > On 23/11/17 12:28, Arnt Karlsen wrote:
> > > ..the kernel guys has this far proven more trustworthy, IME.  
> > 
> > Number of times unknown third parties have inserted bad code into the 
> > linux kernel: 1.

If we want to tell the entire truth about that, the kernel development
chain was not compromised in the 2011 breach.  All of the canonical
kernel source in git and all of the sha1-signed patchsets were untouched.

The compromise was of several of the kernel.org servers probably via
stolen developer ssh credentials.  This is thus something else entirely.  
For a couple of years, a detailed forensics report was promised[1] but
never appeared.  I made an issue of this a few years ago on LWN.net and
elsewhere including with some friends among the Linux kernel developer
community, and got only lame and passive-aggressive brush-offs.
 
> ..only once?  Don't forget the runtime backdoor attacks.

Again, this is distortive without the _entire_ truth.  Once again, you
are not talking about any compromise of the kernel development chain.
You are talking about someone breaking into _way_-downstream points of
distribution, such as for example an eastern European intruder who
compomised Linux Mint's Web site (via some hapless unfixed vulnerability
that I cannot find at the moment).  Having the ability to edit the Linux
Mint Web site, the intruder altered the mirror site page to point some
downloaders to an unauthorised site in Bulgaria that served up trojaned
copies of Linux Mint that had backdooring built into the (fraudulent)
distro kernel.

That _obviously_ is not the same as a security problem with the kernel
itself, and I'm disappointed that both you and John are distorting the
truth by implication.

Blaming the kernel developers for that would be like blaming my
Kryptonite bicycle lock for weakness against burglars after someone
picks it up and hands it to a burglar.

For completeness, as long as we are ponying up phony examples of 'third
parties inserting bad code into the Linux kernel', one could cite the
2003 attempt to backdoor kernel sources via the BitKeeper-to-CVS
gateway
(https://linux.slashdot.org/story/03/11/06/058249/linux-kernel-back-door-hack-attempt-discovered).
But, again, tell the _entire_ truth:  That gateway was an export from
the kernel development chain, not part _of_ the development chain.  The
actual canonical kernel source, then kept in BK, was untouched along
with all the signed patchsets.  This was shortly before McVoy ended the 
kernel team's use of BK and Linus & friends immediately developed git to
replace it.

Seriously, guys, less bullshit on security matters, please.  Some of us
can actually detect it and find it annoying.


[1] E.g., on the front page's Site News
(http://web.archive.org/web/20111004011725/http://kernel.org/) an item
later quietly dropped.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs

[Arnt Karlsen]

On Thu, 23 Nov 2017 11:32:57 +0100, John wrote in message 
<51f391b3-2c10-78b0-d1ce-39f56f8e0...@atlantech.com>:

> Replying directly because Jaromil has said I am not welcome.

..no problem, I'll cc the list. ;o)

> On 23/11/17 11:06, Arnt Karlsen wrote:
> 
> > ..which leaves in place that "systemd"-filter we wanna avoid...  
> 
> You're worrying that journalctl will filter out stuff before showing
> it to you?

..yep.

> Why aren't you worrying that journald has filtered it out before
> writing it to the journal?

..but I do.

> Or that the kernel has filtered it out before sending it to journald?

..the kernel guys has this far proven more trustworthy, IME.

..but I agree there's a potential right there too, and I see you 
systemd guys may have found ways to defeat the kernel guys, or 
e.g. the Tor project.
If you systemd guys turn out to be the good guys, you become 
part of my back-up plan.  

..clearly, one of our sides (systemd vs Devuan/Tor/kernel/etc) 
are on the right side and the other side is on the wrong side.
And, sometimes the good guys have to pretend they are the bad 
guys, to catch bad guys. 
That's why we all need back-up plans. ;o)

> > ..those 2 ways forward are viable starting points that will help
> > the proper way to deal with suspect code, Samba style
> > re-engineering, which has brought us all e.g. wine,  
> 
> Why the comparison with Samba and wine?  You have the source code for 
> systemd available.

..aye.  And then we have the good old Ken Thompson style compiler 
hacks and 33 years of water under the bridge to come up with even 
better hacks...

> >> Intimate knowledge?  No, all it requires knowing is that most of
> >> the fields in a systemd journal are ascii keyword=value pairs.  
> > ...which we must guess correctly where to find ...  
> 
> Uh, they're in the journal file.  Where else would you expect them to
> be?

..hidden away everywhere.

> >> Tell you what, I'll see if I can write a little perl script to
> >> output a systemd journal in a format a little more pretty than
> >> strings(1) for you, give me a day, ok?  
> > ..thanks, I'll try it. :o)  
> 
> I'm slightly less motivated to write it now I've been sent to the 
> naughty stool, but I'll try get around to it in a few days.

..thanks, I'll be patient. ;o)


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs

[Arnt Karlsen]

On Thu, 23 Nov 2017 08:20:05 +0100, John wrote in message 
<25c55d20-a650-5ec7-5943-f2224ba21...@atlantech.com>:

> On 22/11/17 17:35, Arnt Karlsen wrote:
> > ..to reiterate: Is there a way to decode and read those binary
> > systemd journal logs on classic POSIX/Unix etc forensic systems
> > _not_ running systemd?  
> 
> Of course.
> 
> Either install a tool that does it for you, i.e. journalctl,

..which leaves in place that "systemd"-filter we wanna avoid...

> or write
> a tool to do it using the publicly available documentation.

..which assumes that that documentation is truthful etc.

..those 2 ways forward are viable starting points that will help 
the proper way to deal with suspect code, Samba style re-engineering,
which has brought us all e.g. wine, 

> > ..the "strings" approach suggested by John Hughes requires an
> > intimate knowledge of systemd and might be relevant if the
> > investigations were on "systemd sabotaging Devuan playing _new_
> > zero-day dirty tricks."  
> 
> Intimate knowledge?  No, all it requires knowing is that most of the 
> fields in a systemd journal are ascii keyword=value pairs.

...which we must guess correctly where to find ...

> Tell you what, I'll see if I can write a little perl script to output
> a systemd journal in a format a little more pretty than strings(1)
> for you, give me a day, ok?

..thanks, I'll try it. :o)

> > ..so, the systemd crowd should have an interest in e.g. exposing
> > "Devuan incompetence and paranoia" by coming up with an easy way
> > to decode and read binary systemd journal logs without having to
> > run systemd, to prove their case on "Devuan incompetence and
> > paranoia on systemd", rather than confirm my current belief.  
> 
> incompetence is your word, not mine.  Paranoia seems to fit some 
> people.  For example, what do you mean by "_new_ zero-day dirty
> tricks" above?

..the bad guys likes to move fast with their best toys,
e.g. on Election Day in voting machines.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs

[John Hughes]

On 22/11/17 17:35, Arnt Karlsen wrote:

..to reiterate: Is there a way to decode and read those binary
systemd journal logs on classic POSIX/Unix etc forensic systems
_not_ running systemd?


Of course.

Either install a tool that does it for you, i.e. journalctl, or write a 
tool to do it using the publicly available documentation.



..the "strings" approach suggested by John Hughes requires an intimate
knowledge of systemd and might be relevant if the investigations were
on "systemd sabotaging Devuan playing _new_ zero-day dirty tricks."


Intimate knowledge?  No, all it requires knowing is that most of the 
fields in a systemd journal are ascii keyword=value pairs.


Tell you what, I'll see if I can write a little perl script to output a 
systemd journal in a format a little more pretty than strings(1) for 
you, give me a day, ok?



..so, the systemd crowd should have an interest in e.g. exposing
"Devuan incompetence and paranoia" by coming up with an easy way
to decode and read binary systemd journal logs without having to
run systemd, to prove their case on "Devuan incompetence and
paranoia on systemd", rather than confirm my current belief.


incompetence is your word, not mine.  Paranoia seems to fit some 
people.  For example, what do you mean by "_new_ zero-day dirty tricks" 
above?


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs

[Arnt Karlsen]

On Wed, 22 Nov 2017 12:58:10 +, Arnt wrote in message 
<6ff3d9c1-e23c-4b0e-af51-5f8db1425...@gulbrandsen.priv.no>:

> Arnt Karlsen writes:
> > you appear to suggest that law enforcement wanting to read systemd
> > journal logs, _should_ depend on the mercy of systemd developers
> > not "filtering" away inconvenient evidence of e.g. systemd developer
> > wrongdoing from said law enforcement.  
> 
> That's routine. Few readers read everything that can be read. For
> example, look at postgres. Its binary file format reveals quite a bit
> more than you can get using psql, and by design: The writer and
> binary format are intended for storing things quickly and reliably,
> and the reader for reading what was stored. Anything that's in the
> file but wasn't stored by instruction of an SQL user is uninteresting
> to psql, and the file format writer has no particular reason to avoid
> storing other information.
> 
> If you really want to look at the details in postgres, you can take a
> good guess at whether two rows were inserted at the same time or one
> later than the other.
> 
> That's why forensics people use the files. Systemd is about the
> millionth system to join the club. Flame postgres and vast numbers of
> others before you flame systemd. Or better yet, limit your statements
> about systemd to what's correct.
> 
> Arnt


..it is very nice to learn I can read e.g. postgresql database files
while boycotting e.g. postgresql, using strings and all sorts of fancy
tricks to e.g. verify some postgresql developer's statement on systemd
people playing nice or not.  

..it would also be very nice to learn of a way to decode and read binary
systemd journal logs without having to run systemd or without having 
to hire expensive expert witnesses to decode and read my own binary
systemd journal logs from my final days on Debian Jessie.

..one very nice way of learning of a way to decode and read binary
systemd journal logs without having to run systemd, is listening 
to wise answers from those who knows the correct truth about how 
to decode and read our own binary systemd journal log files. ;o)

..so, how about answering my question?  
Preferably correctly, if at all possible.  
If not, pointers to hearsay is useful to help try discover 
the (ugly?) truth. 
All I've seen this far, is confusion, deflection, trolling 
and diversion away from the context and my question. 


..to reiterate: Is there a way to decode and read those binary
systemd journal logs on classic POSIX/Unix etc forensic systems 
_not_ running systemd?  


..e.g. using my namesake's example postgresql to translate the binary
files into some human-readable format?

..the "strings" approach suggested by John Hughes requires an intimate
knowledge of systemd and might be relevant if the investigations were 
on "systemd sabotaging Devuan playing _new_ zero-day dirty tricks."

..so, the systemd crowd should have an interest in e.g. exposing
"Devuan incompetence and paranoia" by coming up with an easy way 
to decode and read binary systemd journal logs without having to 
run systemd, to prove their case on "Devuan incompetence and 
paranoia on systemd", rather than confirm my current belief.  



-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[Didier Kryn]

Le 22/11/2017 à 16:46, Arnt Gulbrandsen a écrit :

Didier Kryn writes:
    Well, postgress is a database manager. You have a choice of 
several others; they must be able to deal with high fluxes of data. 
None of them is a critical system component.


WTF? Postgres is a critical system component of every single server 
where I've ever installed that. The data in Postgres and the software 
that accesses it are the reason why the server exists at all.


    Good point, I tend to forget that there are special needs for heavy 
duty servers; but see below.
    System logs are a critical system component and they don't face 
high fluxes of data. You can, in principle, use syslog for 
applications with a high flux of logs, but it's at your own risk.


Are you saying one should not use syslog for events caused by 
untrusted users?


    If the reason for having binary logs is performance, it means you 
are dealing with really massive logs. If untrusted users cause gigabytes 
of logs per day, you can either filter them online, which rsyslog can do 
pretty well, or try to use another method. I may have missed something, 
but I doubt anybody will ever read such massive logs. Also remember that 
syslog() uses one single socket and lock for all processes in the 
system, which means that emmiting a log message may imply waiting on a 
queue. If you write your own application, you can bypass the syslog() 
bottleneck in a number of ways.


    Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[Arnt Gulbrandsen]

Didier Kryn writes:
Well, postgress is a database manager. You have a choice of 
several others; they must be able to deal with high fluxes of 
data. None of them is a critical system component.


WTF? Postgres is a critical system component of every single server where 
I've ever installed that. The data in Postgres and the software that 
accesses it are the reason why the server exists at all.


System logs are a critical system component and they don't 
face high fluxes of data. You can, in principle, use syslog for 
applications with a high flux of logs, but it's at your own 
risk.


Are you saying one should not use syslog for events caused by untrusted 
users?


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[Didier Kryn]

Le 22/11/2017 à 13:58, Arnt Gulbrandsen a écrit :
If you really want to look at the details in postgres, you can take a 
good guess at whether two rows were inserted at the same time or one 
later than the other.


    Well, postgress is a database manager. You have a choice of several 
others; they must be able to deal with high fluxes of data. None of them 
is a critical system component.


    System logs are a critical system component and they don't face 
high fluxes of data. You can, in principle, use syslog for applications 
with a high flux of logs, but it's at your own risk.


    Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[Clarke Sideroad]

On 2017-11-22 09:46 AM, Arnt Gulbrandsen wrote:

Aldemir Akpinar writes:

No, I've actually asked an honest question.


In that case you'll get my honest answer. I've implemented several 
file/network formats vaguely like that journal format, one of them has 
likely been used by millions of people.


In each case, the team decided to use a header/packet format, because 
that made both writing and reading simple. In the case of the network 
format we additionally included a magic number to catch version skew, 
and did it using binary because that made for the simplest reading 
code. Reading a 16-byte header using read(2) is simpler than reading a 
textual header.


I don't remember anyone on either of the teams suggesting that using 
text had advantages for developers or users. Generally we just chose 
what was easier to ship reliably and parse/generate with simple code.


In one case we used binary because even though the data were readable 
text, they weren't editable (the actual format had non-trivial 
restrictions). I don't remember the details, but for some reason we 
worried that people would hand-edit files and cause problems deep 
inside the reading program.


I find it totally plausible that the systemd people would design the 
format for similar concerns and end up a format where a fixed-size 
header includes a tag type and length, then a variable-sized packets 
mostly containing log lines, and then another header. That kind of 
thing is so easy to read and write using 
https://linux.die.net/man/2/read and its companion functions.


It is all a trade-off, making choices in implementation, and choice IS a 
good thing to have (Insert thumbs up to Devuan here), I don't think 
anybody is disputing that.


This sub-thread mentions forensics, which to me means analysis of a 
system, a snapshot in time or worst case after complete failure.


Due to the nature of things one is always going to be faced with binary 
files somewhere in the analysis that may or may not be easily 
decode-able or even recoverable.


There is no question in my mind that a broken plain text file is far 
easier to traverse and sort out, which is really what the finger 
pointing game going on here is all about.


Choice is good, having "no choice" forced upon you is bad, end of story.

Clarke





___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[Arnt Gulbrandsen]

Aldemir Akpinar writes:

No, I've actually asked an honest question.


In that case you'll get my honest answer. I've implemented several 
file/network formats vaguely like that journal format, one of them has 
likely been used by millions of people.


In each case, the team decided to use a header/packet format, because that 
made both writing and reading simple. In the case of the network format we 
additionally included a magic number to catch version skew, and did it 
using binary because that made for the simplest reading code. Reading a 
16-byte header using read(2) is simpler than reading a textual header.


I don't remember anyone on either of the teams suggesting that using text 
had advantages for developers or users. Generally we just chose what was 
easier to ship reliably and parse/generate with simple code.


In one case we used binary because even though the data were readable text, 
they weren't editable (the actual format had non-trivial restrictions). I 
don't remember the details, but for some reason we worried that people 
would hand-edit files and cause problems deep inside the reading program.


I find it totally plausible that the systemd people would design the format 
for similar concerns and end up a format where a fixed-size header includes 
a tag type and length, then a variable-sized packets mostly containing log 
lines, and then another header. That kind of thing is so easy to read and 
write using https://linux.die.net/man/2/read and its companion functions.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[John Hughes]

On 22/11/17 15:08, Aldemir Akpinar wrote:


On 22 November 2017 at 17:03, John Hughes > wrote:


On 22/11/17 14:18, Aldemir Akpinar wrote:


Could you elaborate why are you comparing a relational database
system where its files must be binary with a logging system where
its files doesn't need to binary?



Need?  Nothing "needs" to be in binary[*].  It's a design
decision.  Do the advantages of a structured format (mostly speed)
override the disadvantages (higher costs for access if the reader
software is unavailable?





That's still not the answer to my question!


There is no simple answer to your question because your question 
contains the logical fallacy of "begging the question", i.e. the 
question assumes its own answer.


You said "why are you comparing a relational database system where its 
files must be binary with a logging system where its files doesn't need 
to binary?"


That assumes that the files of a relational database system *must* be 
binary, which is simply untrue and that there is no advantage to making 
the files of a logging system binary which is debatable.


The answer to your question is that there is no one single answer.  The 
system designer will make his decisions about the different tradeoffs.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[Dave Turner]

On 22/11/17 14:22, Arnt Gulbrandsen wrote:

Aldemir Akpinar writes:
Could you elaborate why are you comparing a relational database 
system where its files must be binary with a logging system where its 
files doesn't need to binary?


You make it sound is if binary files were some sort of horror that 
requires special justification. Please argue the point. Does a text 
format justify x% performance loss? y% increase in line count or code 
complexity? Pick x/y.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


My understanding of why text files are better for important system logs 
is this:-


When your server goes down big-style and you get all sorts of file 
corruption you stand a very good chance of working out what happened 
even if your text format log file is a bit mangled.


If your binary format log file is mangled life is considerably more 
difficult - ask those that look after Microsoft Servers. I did, 'that's 
as bad as Windows!' he said.


DaveT

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[Aldemir Akpinar]

On 22 November 2017 at 17:22, Arnt Gulbrandsen 
wrote:

> Aldemir Akpinar writes:
>
>> Could you elaborate why are you comparing a relational database system
>> where its files must be binary with a logging system where its files
>> doesn't need to binary?
>>
>
> You make it sound is if binary files were some sort of horror that
> requires special justification. Please argue the point. Does a text format
> justify x% performance loss? y% increase in line count or code complexity?
> Pick x/y.
>
>
> Arnt
>
>
>
No, I've actually asked an honest question. I didn't imply anything at all.
But all I get is trolling, not an answer to my Q :)

Anyway, I'm done with these e-mails today. Doesn't help Devuan at all.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[Arnt Gulbrandsen]

Aldemir Akpinar writes:
Could you elaborate why are you comparing a relational database 
system where its files must be binary with a logging system 
where its files doesn't need to binary?


You make it sound is if binary files were some sort of horror that requires 
special justification. Please argue the point. Does a text format justify 
x% performance loss? y% increase in line count or code complexity? Pick 
x/y.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[Aldemir Akpinar]

On 22 November 2017 at 17:03, John Hughes  wrote:

> On 22/11/17 14:18, Aldemir Akpinar wrote:
>
>
> That's routine. Few readers read everything that can be read. For example,
>> look at postgres. Its binary file format reveals quite a bit more than you
>> can get using psql, and by design: The writer and binary format are
>> intended for storing things quickly and reliably, and the reader for
>> reading what was stored. Anything that's in the file but wasn't stored by
>> instruction of an SQL user is uninteresting to psql, and the file format
>> writer has no particular reason to avoid storing other information.
>>
>>
>>
>>
> Could you elaborate why are you comparing a relational database system
> where its files must be binary with a logging system where its files
> doesn't need to binary?
>
>
> Need?  Nothing "needs" to be in binary[*].  It's a design decision.  Do
> the advantages of a structured format (mostly speed) override the
> disadvantages (higher costs for access if the reader software is
> unavailable?
>
> [*] or, to put it another way -- *everything on a computer is in binary*.
> "Text" files are binary.  The question is how easy is it to decode the file
> format.  It seems obvious that a "text" file is easy to decode, everyone
> knows the format (but what character set is it in?), but don't forget that
> the "text" file is stored on a filesystem, which is itself a complicated
> "binary" structure.  When you're talking about "forensics", i.e. looking at
> something that may be broken in exciting ways, it's quite naïve to assume
> that you can just mount the filesystem (which one?) and use cat, vi, grep
> or whatever.
>
>

That's still not the answer to my question!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[John Hughes]

On 22/11/17 14:18, Aldemir Akpinar wrote:


That's routine. Few readers read everything that can be read. For
example, look at postgres. Its binary file format reveals quite a
bit more than you can get using psql, and by design: The writer
and binary format are intended for storing things quickly and
reliably, and the reader for reading what was stored. Anything
that's in the file but wasn't stored by instruction of an SQL user
is uninteresting to psql, and the file format writer has no
particular reason to avoid storing other information.




Could you elaborate why are you comparing a relational database system 
where its files must be binary with a logging system where its files 
doesn't need to binary?




Need?  Nothing "needs" to be in binary[*].  It's a design decision. Do 
the advantages of a structured format (mostly speed) override the 
disadvantages (higher costs for access if the reader software is 
unavailable?


[*] or, to put it another way -- *everything on a computer is in 
binary*.  "Text" files are binary.  The question is how easy is it to 
decode the file format.  It seems obvious that a "text" file is easy to 
decode, everyone knows the format (but what character set is it in?), 
but don't forget that the "text" file is stored on a filesystem, which 
is itself a complicated "binary" structure.  When you're talking about 
"forensics", i.e. looking at something that may be broken in exciting 
ways, it's quite naïve to assume that you can just mount the filesystem 
(which one?) and use cat, vi, grep or whatever.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[Aldemir Akpinar]

> That's routine. Few readers read everything that can be read. For example,
> look at postgres. Its binary file format reveals quite a bit more than you
> can get using psql, and by design: The writer and binary format are
> intended for storing things quickly and reliably, and the reader for
> reading what was stored. Anything that's in the file but wasn't stored by
> instruction of an SQL user is uninteresting to psql, and the file format
> writer has no particular reason to avoid storing other information.
>
> If you really want to look at the details in postgres, you can take a good
> guess at whether two rows were inserted at the same time or one later than
> the other.
>
> That's why forensics people use the files. Systemd is about the millionth
> system to join the club. Flame postgres and vast numbers of others before
> you flame systemd. Or better yet, limit your statements about systemd to
> what's correct.
>
> Arnt
>

Could you elaborate why are you comparing a relational database system
where its files must be binary with a logging system where its files
doesn't need to binary?

--
aldemir
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[Arnt Gulbrandsen]

Arnt Karlsen writes:

you appear to suggest that law enforcement wanting to read systemd
journal logs, _should_ depend on the mercy of systemd developers not 
"filtering" away inconvenient evidence of e.g. systemd developer

wrongdoing from said law enforcement.


That's routine. Few readers read everything that can be read. For example, 
look at postgres. Its binary file format reveals quite a bit more than you 
can get using psql, and by design: The writer and binary format are 
intended for storing things quickly and reliably, and the reader for 
reading what was stored. Anything that's in the file but wasn't stored by 
instruction of an SQL user is uninteresting to psql, and the file format 
writer has no particular reason to avoid storing other information.


If you really want to look at the details in postgres, you can take a good 
guess at whether two rows were inserted at the same time or one later than 
the other.


That's why forensics people use the files. Systemd is about the millionth 
system to join the club. Flame postgres and vast numbers of others before 
you flame systemd. Or better yet, limit your statements about systemd to 
what's correct.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?

[Arnt Karlsen]

On Wed, 22 Nov 2017 07:19:20 +0100, John wrote in message 
:

> On 22/11/17 02:59, Arnt Karlsen wrote:
> > On Tue, 21 Nov 2017 18:21:14 +0100, John wrote in message
> > :
> >  
> >> (Damn but the systemd journal is great :-))  
> > ..is there a way to decode and read those binary systemd journal
> > logs on classic POSIX/Unix etc forensic systems _not_ running
> > systemd?  
> 
> Is there any way to read a file in format X without a program that
> reads format X?

..I'm asking you.  Your other "answers" to this question suggests 
you may know the true answer to my question.

> I suppose you could scatter iron filings on the disk the use a
> scanning electron microscope to examine their positions and, using
> paper, pencil and a copy of the systemd doc work out the contents by
> hand.
> 
> Or, being endowed with the minimum level of foresight necessary for 
> survival have a forensic system that includes tools for reading the
> file formats you're likely to find  on the system you want to
> post-mortem.

..correct, that is precisely why I went for devuan and precisely why 
I ask you here now.  

..you appear to suggest that law enforcement wanting to read systemd
journal logs, _should_ depend on the mercy of systemd developers not 
"filtering" away inconvenient evidence of e.g. systemd developer
wrongdoing from said law enforcement.

..depending on your jurisdiction, this feature of systemd is either 
a good thing or a bad thing, probably both and probably capable of
facilitating the cover-up of organised crime, AFAICT.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng