RBAC policy for tcpdump

for which I don't blame in the least the grsecurity/PaX developers, but the thieves that compelled them to such action...

[I hope after the sad news] there will still be both: the grsecurity-hardening in Gentoo (and Archlinux) remaining as the best --if not the only true-- option for security-aware users in our surveillance-infested societies, and: there will be a way to spread grsecurity as free program ever more in the *nix world.

For the above two being negatively effected, it is limitedly so: the stable grsecurity not anymore published doesn't affect many people like me at all: I like to tinker with the testing sets in mostly all that I use, build, and install in Gentoo.

You can see the (possible) discussion (little there yet at the time of this writing) at:

If I learn who did it, I won't keep it to myself, but I won't talk about it here in grsecurity forums, but there, in Gentoo Forums.

I made this digression here because I'm still reeling from that sad news.

But the topic is about tcpdump. I'm having difficulty with getting my tiny primitive uncenz program to work with tcpdump.

Because lots of people (read on the Wireshark mailing list), use tcpdump rather than dumpcap, and I would like, some day, that my little (primitive) program can serve non-advanced users by being easily installed even for newbies! Some day, if ever (unless somebody else takes the task to do it; I learn and work at turtle speed...).

uncenz works fine with the Wireshark's dumpcap, but regardless that dumpcap and tcpdump (and there are others), all use the same libpcap library, they work differently, and esp. with grsecurity RBAC roles, there is no simple replacement one for the other in the scripts.

And it's the RBAC policy for tcpdump that I have stumbled upon.

The following stretch may be Gentoo-specific, but it is likely that other distros have similar options and issues, so I hope will be (somewhat) generally useful.

That shows the defaults which I installed tcpdump package with, in my Gentoo. I could have gone the suid option instead (or the libressl, which is completely unchartered, unknown territory to me, for that matter), but I got those with the defaults that the devs in Gentoo set, and I hope I'll be happy with them, for now.

But I have made other changes. If fact, I have made so many attempt at changes (mostly wrong changes; that is, untill I figured out the principles told in my Gentoo setup for tcpdump above), that I am now only able to reproduce (actually figure out which they were), by comparing the two days ago backed-up policy with the current working-and-learning policy.

(which also is unimportant here, but it tells me tcpdump is capturing).

And now I can plug into the ADSL router (I never am online, unless I uncenz), and go to grsecurity forums and post this.

And I'll go with the Fox this time around, to analyze the Perfect Forward Privacy, and learn possibly from how it is deployed on grsecurity forums (I learned the other day how great it is deployed on Bruce Schneier's website!)...

because I opened http://www.gentoo.org by mistake with the '28' pair, and I want to see what I get by contacting sole websites, and so I didn't connect to grsec with that one.

Re: RBAC policy for tcpdump

Posted: Tue Oct 27, 2015 9:26 pm

by timbgo

[quote=In the previous post I]And I'll go with the Fox this time around, to analyze the Perfect Forward Privacy (PFP), and learn possibly from how it is deployed on grsecurity forums (I learned the other day how great it is deployed on Bruce Schneier's website!)...

because I opened http://www.gentoo.org by mistake with the '28' pair, and I want to see what I get by contacting sole websites, and so I didn't connect to grsec with that one.And now I can plug into the ADSL router (I never am online, unless I uncenz), and go to grsecurity forums and post this.[/quote]What I thought wasn't within reach of common mortals, i.e. poor users like me, the decrypting of the SSL conversations, is perfectly possible: SSL Decode & My Hard-Earned Advice for SPDY/HTTP2 in Firefox.

E.g., while on my F(iref]ox's conversations (my dream is that the same mechanisms, the NSS, will be deployed in my preferred, but incomplete browser: the Dillo) with grsecurity's website server noone can really eavesdrop easily at all, as it is SSL-encrypted, with the Network Security Services and the right setup in Wireshark, I can decrypt and dump the contents of those conversations.

Not to make this topic too voluminous, but kind of remaining, in a more broader way, within the topic of the tcpdump which I need for my uncenz, and for all of which I need to be able to correctly deploy grsecurity, and hopefully teach a few newbies to this beautiful area of FOSS that grsecurity is, how to do that by, some day, using my uncenz as aid in fighting intrusions, surveillance and censorship...

So [not to make this topic too voluminous], just a snippet of what the uurlencoded stream that my Fox sent to grsecurity server looked like in the said screencast and the said traffic dump, which, uurlencoded, I got by decrypting the PFP-encrypted conversation:

Just so the entire picture, huga part of it yet to be painted (the uncenz is still more of a dream and if already potentially useful, not of easy deployment for newbies at all)...

[Just so the entire picture] of which one important part, whithout which the picture would be without security, so could not possibly last, is: grsecurity, be a little clearer.

Re: RBAC policy for tcpdump

Posted: Tue Oct 27, 2015 9:27 pm

by timbgo

As it is visible in the first post, I wasn't able to run uncenz program really, with tcpdump instead of dumpcap.

Uncenz is twofold: captures the screen when you open places on the internet, and in the same period, captures the network traffic to and from those places that you go.

With dumpcap, and with it's RBAC policy, as shown, and which policies I linked to (in the Wireshark topic on these forums), I can start uncenz with one command only, and stop it with one command.

I want to be able to do the same with using tcpdump instead of dumpcap.

So the uncenz has to be started from one terminal only (and not from two, which I currently can do to achieve what I want uncenz for: one terminal the normal user, to run ffmpeg to screencast, and one root terminal to run tcpdump.

I have looked into running uncenz as root, and using sudo to ffmpeg-screencast as normal user. Didn't manage to do it.

Next, I'll try and see if I can run (tcpdump-)uncenz from normal-user terminal, and what the messages will tell me, so I can eventually build the right RBAC policies for it.

(Just to recall that the RBAC learning is on all the time, as verbosely explained in the first post.)

Another Gentoo-specific piece of information, other distros users take out the underlying principles, pls.

I've been figuring out how to do it for the most of this day, and (only) I now think that I will probably have to add the suid flag, as it is not in any contradiction to the drop-root flag which is on by default in Gentoo (why did it take me so long?).

It is not on, the suid, by default, why?, is it because it probably entails a little extra security risk, or because users mostly just run tcpdump in their root terminals? Can't say. I have too little experience with tcpdump so far...

But let me show you what happens if tcpdump is not installed with suid use-flag.

All the investigation is only possible because I always have these on, in by grsecurity setup:

All that I talked in the first post can be seen here, and all works fine.

Even the 'denied socket' lines in bottom are just fine, because I don't want that the X-empoying Wireshark captures for me. I really don't think there are many people in the whole world who can really follow in much detail all and exactly what happens when Wireshark captures. It goes so fast that it's not up to homans the internalizing of all the information...

And it must be safer without the X-employing Wireshark capturing traffic, but rather with tcpdump (or dumpcap)!

I do need Wireshark, though, for reading the captured dumps!

All is there, just I won't, for brevity, show the ffmpeg screencasting that is, surely, also recorded so fine with grsec... and which I started a number of seconds later (as I needed to paste the right infix, as explained, in the screencast file to be).

Now, if the commands that got me the tcpdump'ing correctly were, in the root terminal (the expanded version):

what do I need to issue, to get the tcpdump'ing to happen in a normal user terminal?(BTW, I needed not, as you read in the last line, the 'sudo -s'; it would have worked without it just fine, I believe. Not an error, but not needed, I believe.)

But I'll need a few more of 'sudo -s' calls, or 'sudo -u tcpdump', don't know yet, from a normal user terminal.

That, the the paste in the previous post, is the complete, and in no detail, changed lines from my /var/log/messages.

It contains me with my editor vim editing the /etc/portage/package.use, and listing it successfully having been written to, because its timestamp changed. However, in the log, it is shown as if I wasn't able to write to it!

The terminal in which I have had vim opened for many hours now, has due to me having changed the /etc/grsec/policy file, and disabled adn enabled gradm, lost the admin status:

# grep RBAC /proc/$$/statusgrep: /proc/3734/status: No such file or directory#

But vim had written where it should not have been allowed to write...

I have to post this, because it looks buggy to me, so grsecurity devs can see if they need to look into it more closely.

I won't change anything in the last three posts that I will post, and which I have prepared in the span of a number of hours (exactly since I posted the first post (only work and a short nap in the meantime), so the buggy behavior may be seen sooner.

To end a session issue "uncenz-kill <Enter>" from its terminal.miro@g0n /Cmn/mr $

And that means I can't go online, not unless I can capture traffic with tcpdump, and screencast with ffmpeg, as I had previously (seeing that the months-long all-the-time-working uncenz all of a sudden does not work...)...

Re: RBAC policy for tcpdump

Posted: Sat Nov 07, 2015 9:36 am

by timbgo

I had to, for now, postpone the solving of this issue.

Also, for the readers who noticed that I saw something buggy, I did, and I tried to start reporting it, but unfortunately, poor health along with my insufficient competence, and my incomplete control on what and how I was presenting it, all these were the reasons that I was unable to prepare how to reproduce it, to later be able to present what happened.

I don't have the time to look up AppArmor, and I'm generally more than happy with RBAC (once I learned to use it) and with grsec generally. I think grsec really keeps my machine as safe as possible, and I don't want to belittle anyone, but it is the grsecurity and PaX programs (the twin program that we call grsecurity for short, and for simple), that brought into the kernel and surrounding programming the real changes.

Wihch real changes were fought against and thwarted in many ways by many little people who behave and think themselves big and clever, from various quarters...

And for which changes there is so little acknowledgement, not to say gratitude, because frankly gratitude would be due, that spender and PaX Team, and other grsecurity developers, receive.

I strongly disbelieve there can hardly be better hardening than grsecurity. The wisdom they ushered has changed the industry, and while not seeing the future, and not knowing what future holds (but strongly hoping and wishing for more years of at least relative peace and calm work for these developers)... how should I expect to find solutions, based on their inventions, somewhere else, and implemented as good, let alone better, than these inventors of these methods, have implemented them?

Will be back to work on tcpdump policies, but not soon. Busy elsewhere.

Cheers!

Re: RBAC policy for tcpdump

Posted: Sun Jan 15, 2017 12:28 am

by timbgo

I've [likely] solved the tcpdump policy issue.

And I have reworked the uncenz scripts so that with some possible tweaking, you can use them to capture traffic with either dumpcap or tcpdump.

But the important thing, esp. for newbies searching for some understanding in creating the policy for their systems, is what I didn't clearly understand how to do up until maybe a week ago (I have only now found time for posting this), is how to set up the learning.

The "drop-root" useflag in the top post of this topic, is there so that tcpdump can drop all the privileges and run as user tcpdump and group tcpdump, because there is the tcpdump entry in the /etc/passwd and also tcpdump entry in the /etc/group .

And the learning needs to be done on the role tcpdump (along with some other learning).

Re: RBAC policy for tcpdump

Posted: Wed Apr 05, 2017 12:07 pm

by timbgo

In the topic:Qemu RBAC policies (& libvirt & tcpdump...) viewtopic.php?f=5&t=4691I made some corrections with regard to RBAC policy for tcpdump, after I started figuring out more in earnest in the:Libvirt virtualization policiesviewtopic.php?f=5&t=4675about getting the roles to learn well