Tails

#2 Updated by intrigeri 2014-05-07 16:45:47

natmaka wrote:
> This is useful during a debug session but may lead to large logs during a long session.

What kind of size are we speaking of here? MiB, dozens of MiB, more?

What practical problem does it cause in your experience?

(I mean, 99% of users don’t care about the logs, and most of those who care can easily filter out
the iptables lines if they want to look only at the rest. But I’m probably missing something here!)

> Suggestion: a way for root to switch between the default mode and a “light log” mode (every iptables LOG logs at most N message per TIME UNIT")

The thing is, enabling logging after the fact is often too late to debug something that already happened. But I’m sure we are open to consider this option, once it is clarified what problem this solution would solve. I’m curious :)

#4 Updated by natmaka 2014-05-11 01:53:02

intrigeri wrote:
> natmaka wrote:
> > This is useful during a debug session but may lead to large logs during a long session.
>
> What kind of size are we speaking of here? MiB, dozens of MiB, more?

Those logs lines occupy approximately 20 MiB after a day-long exploration Tails session, here.

> What practical problem does it cause in your experience?

The underlying idea is that some Tails users are only interested in anonymity, not plausible deniability. They may let a Tails session run for extensive periods of time (days or even weeks …), and even if they don’t explore many new tools, and therefore obtain much less of such logs (much less REJECT/DROP network packets), this may lead to a non-neglectable amount of logs, occupying ramdisk space. No one wants to hear “Tails is just like this other OS, you have to reboot it from time to time” (granted: Tails already sticks to the dreadful “reinstall often!” approach :-) )

> (I mean, 99% of users don’t care about the logs

On Tails any log reduces available fs space even if no one read them.

> and most of those who care can easily filter out the iptables lines if they want to look only at the rest.

Indeed, and they also can reenable full logging, if necessary. Read on.

> > Suggestion: a way for root to switch between the default mode and a “light log” mode (every iptables LOG logs at most N message per TIME UNIT")
>
> The thing is, enabling logging after the fact is often too late to debug something that already happened.

My proposition isn’t “switch the iptables REJECT/DROP logs OFF”, but to cap the rate of each of them. Those iptables REJECT/DROP logs aren’t useful to the user in forensics mode, but in empirical exploration, “reproducible problem solving” mode. I mean if a software doesn’t work because a network packet is rejected and if you don’t know about iptables you’re stuck even with full logs, and if you’ve enough knowledge to read the log you will monitor them while redoing whatever you tried, and probably catch a pertinent message even if a realistic “—limit” is enforced. In fact “—limit” will probably reduce the time needed to find the answer. Even in the worst case, even you’re stuck at this stage because there are too many potentially pertinent logs masking the useful ones you will explore the iptables active ruleset, grok the —limit forms, explore the iptables/ferm/whatever parameters script or documentation and find a comment about a way to enable/disable/parametes those —limits …

This is not a major concern but a way to better serve everyone in some corner cases.

#5 Updated by intrigeri 2014-06-03 09:43:32

Thanks a lot for the detailed explanation.

My understanding is that the problem described here only affects advanced users who install additional software in Tails and experiment with it: software that is shipped in Tails is configured in a way that does not makes iptables logs, apart of a few lines here and there.

Still, better supporting this usecase, by capping the rate of REJECT and DROP log messages by default, feels like a simple and cheap way to make power-users feel more welcome among our community… and more likely to contribute back to the project, perhaps. That’s a low-hanging fruit that would be good to pick.

The debug/production mode (and tools to switch from the one to the other) approach feels needlessly complicated, though: I think I’d prefer to see a first iteration simply apply some capping by default, and leave it to those who need full logs to re-configure the firewall by hand to drop the limit. Of course, once the first iteration is completed, I certainly would not mind seeing this (debug/production modes) improvement added.

Nat, does such an approach make sense to you? If it does, then I’ll do whatever ticket mangling is necessary.

> (granted: Tails already sticks to the dreadful “reinstall often!” approach :-) )

To me, having to upgrade the read-only part of a system regularly feels much closer to the good old apt-get dist-upgrade than to re-installing (and having to reconfigure everything from scratch), so I’m not sure the comparison really holds. Moreover, incremental (“automatic”) upgrades are a game-changer in this respect. Anyway, that’s off-topic as far as this ticket is concerned.

Cheers!