RBAC policy for tcpdump

Submit your RBAC policies or suggest policy improvements

Moderators: spender, PaX Team

RBAC policy for tcpdump

Postby timbgo » Tue Oct 27, 2015 1:48 pm

title: RBAC policy for tcpdump
---

I hope after the sad news:

https://www.grsecurity.net/announce.php

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:

(the current title) grsecurity withdrew support for stable; who did it to them?
https://forums.gentoo.org/viewtopic-t-1031476.html

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.

Code: Select all
# emerge -p tcpdump

These are the packages that would be merged, in order:

Calculating dependencies            ... done!                   
[ebuild   R    ] net-analyzer/tcpdump-4.7.4-r1::gentoo  USE="drop-root ipv6 smi ssl -libressl -samba -suid {-test}" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB
#

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.

Just looked up what I would get it I tried:
Code: Select all
# export USE=libressl ; emerge -p tcpdump
These are the packages that would be merged, in order:

Calculating dependencies     ... done!         
[ebuild  N     ] dev-libs/libressl-2.2.4:0/35::gentoo  USE="asm -static-libs" ABI_X86="(64) -32 (-x32)" 2,897 KiB
[ebuild   R    ] net-analyzer/tcpdump-4.7.4-r1::gentoo  USE="drop-root ipv6 libressl* smi ssl -samba -suid {-test}" 0 KiB
[blocks B      ] dev-libs/openssl:0 ("dev-libs/openssl:0" is blocking dev-libs/libressl-2.2.4)

Total: 2 packages (1 new, 1 reinstall), Size of downloads: 2,897 KiB
Conflict: 1 block (1 unsatisfied)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (dev-libs/libressl-2.2.4:0/35::gentoo, ebuild scheduled for merge) pulled in by
    dev-libs/libressl required by (net-analyzer/tcpdump-4.7.4-r1:0/0::gentoo, ebuild scheduled for merge)

  (dev-libs/openssl-1.0.2d-r2:0/0::gentoo, installed) pulled in by
...[cut 37 lines here]...
   dev-libs/openssl required by (mail-mta/postfix-3.0.3:0/0::gentoo, installed)
    dev-libs/openssl:0 required by (net-misc/openssh-7.1_p1-r1:0/0::gentoo, installed)
    >=dev-libs/openssl-1 required by (net-analyzer/ssldump-0.9-r2:0/0::gentoo, installed)
    dev-libs/openssl:0 required by (mail-mta/postfix-3.0.3:0/0::gentoo, installed)
    dev-libs/openssl:0 required by (x11-base/xorg-server-1.17.2-r2:0/1.17.2::gentoo, installed)
    dev-libs/openssl:0= required by (net-analyzer/nmap-6.49_beta2-r1:0/0::gentoo, installed)
    dev-libs/openssl:0 required by (dev-lua/luacrypto-0.3.2-r1:0/0::gentoo, installed)

and I know my good friend postfix (which is just one of the programs I couldn't live without in the long list above) recommends opnessl...

Also, I tinkered with tcpdump and my /etc/grsec/policy for hours now, and I like the drop-root way that tcpdump does it in Gentoo.

By now, I have hopefully, in part, solved the policy that I simply couldn't do right by mere adapting the already written dumpcap policy

RBAC policy for Wireshark-2
viewtopic.php?f=5&t=4300

that I have.

My current, working learning policy in my /etc/grsec/policy is:
Code: Select all
# Role: root
subject /usr/sbin/tcpdump ol {
   /            h
   -CAP_ALL
   +CAP_DAC_OVERRIDE
   bind   disabled
   connect   disabled
}


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.

And diffing them, I can see that I modified:
Code: Select all
role root uG
role_transitions admin shutdown
role_allow_ip   192.168.3.0/24
role_allow_ip   0.0.0.0/32
user_transition_allow miro
group_transition_allow miro

into:
Code: Select all
role root uG
role_transitions admin shutdown
role_allow_ip   192.168.3.0/24
role_allow_ip   0.0.0.0/32
user_transition_allow miro tcpdump nobody
group_transition_allow miro tcpdump nobody


(I made many guesses --but some changes were pure knowledge still ;-) -- in my attempts, that I think I'll only later remove the two instances of 'nobody' in the lines above.)

In the:
Code: Select all
# Role: root
subject /bin/bash o {

I added:
Code: Select all
   /usr/sbin/tcpdump   rx

and:
Code: Select all
   +CAP_NET_RAW

(at the right places so the policy is mostly alphabetically ordered)

I replaced:
Code: Select all
# Role: root
subject /usr/bin/sudo o {
group_transition_allow nobody root

with:
Code: Select all
# Role: root
subject /usr/bin/sudo o {
user_transition_allow miro tcpdump nobody
group_transition_allow miro tcpdump nobody

(see about 'nobody' the note further above)

and in that root sudo subject I also added:
Code: Select all
   /usr/sbin/tcpdump   rx


Let me repeat here the main addition:
Code: Select all
# Role: root
subject /usr/sbin/tcpdump ol {
   /            h
   -CAP_ALL
   +CAP_DAC_OVERRIDE
   bind   disabled
   connect   disabled
}


Another one of the non-necessary (but innocuous) changes, is in subject:
Code: Select all
# Role: miro
subject /bin/bash o {

where I also added both:
Code: Select all
   /usr/sbin/tcpdump   rx

and:
Code: Select all
   +CAP_NET_RAW

(see the proverbial note about 'nobody' further above; probably applies here too)

This:
Code: Select all
# Role: miro
subject /usr/bin/sudo o {
user_transition_allow nobody miro root
group_transition_allow nobody miro root

I changed into:
Code: Select all
# Role: miro
subject /usr/bin/sudo o {
user_transition_allow miro root tcpdump nobody
group_transition_allow miro root tcpdump nobody

and added the now proverbial:
Code: Select all
   /usr/sbin/tcpdump   rx

(which is also probably proverbially unnecessary in this story too)

And I'm able to capture with [color]tcpdump[/color] with this setup.

And I'm doing it, as I'm posting this topic to grsecurity forums.

However, I'm not doing it with the not-yet happened: the tcpdump-enabled uncenz little program of mine.

Rather, I have to capture and screencast the old way, something like, as root:

Code: Select all
# dumpfile=dump_$(date +%y%m%d_%H%M)_$(hostname).pcap ; echo $dumpfile ; touch $dumpfile ; chown tcpdump:tcpdump $dumpfile ; ls -l $dumpfile ; read FAKE ; sudo -s tcpdump -i any -w $dumpfile
#

and where the 'read FAKE' that you see in the line above, or let me expand it for you:
Code: Select all
# dumpfile=dump_$(date +%y%m%d_%H%M)_$(hostname).pcap ; \
   echo $dumpfile ; \
   touch $dumpfile ; \
   chown tcpdump:tcpdump $dumpfile ; \
   ls -l $dumpfile ; \
   read FAKE ; \
   sudo -s tcpdump -i any -w $dumpfile


is just the little waiting by the script for me to copy and paste the, e.g. '151027_1828' from this current to be output:
Code: Select all
dump_151027_1828_g0n.pcap
-rw-r--r-- 1 tcpdump tcpdump 0 2015-10-27 18:28 dump_151027_1828_g0n.pcap

into the command line issued as miro:

Code: Select all
$ ffmpeg -f x11grab -nostdin -loglevel 24 -s 1024x768 -r 25 -i :0.0 -c:v libx264 -preset ultrafast -threads 0 Screen_151027_1828_g0n.mkv

(in which the '151027_1828' I manually pasted in).

And then in the miro (the user's) terminal, when I hit Enter, I get:
Code: Select all
No pixel format specified, yuv444p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.

(which is unimportant here, but it tells me ffmpeg is screencasting)
and in the root terminal, when I hit Enter, I get:
Code: Select all
dropped privs to tcpdump
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

(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!)...

---
Just it's actually:
Code: Select all
dump_151027_1838_g0n.pcap

and:
Code: Select all
Screen_151027_1838_g0n.mkv

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.
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia

Re: RBAC policy for tcpdump

Postby timbgo » Tue Oct 27, 2015 9:26 pm

[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!)...

---
Just it's actually:
Code: Select all
dump_151027_1838_g0n.pcap

and:
Code: Select all
Screen_151027_1838_g0n.mkv

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:

Code: Select all
POST /posting.php?mode=post&f=5 HTTP/1.1
Host: forums.grsecurity.net
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://forums.grsecurity.net/posting.php?mode=post&f=5
Cookie: __utma=1.681742131.1445967581.1445967581.1445967581.1; __utmb=1.13.10.1445967581; __utmc=1; __utmz=1.1445967581.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmt=1; phpbb3_2hkkt_u=6484; phpbb3_2hkkt_k=; phpbb3_2hkkt_sid=24b6d2e2e2538f1d4b6ebe1ceb42a414; style_cookie=null
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 13442

subject=&addbbcode20=100&message=title%3A+RBAC+policy+for+tcpdump%0D%0A---%0D%0A%0D%0AI+hope+after+the+sad+news%3A%0D%0A%0D%0Ahttps%3A%2F%2Fwww.grsecurity.net%2Fannounce.php%0D%0A%0D%0Afor+which+I+don%27t+blame+in+the+least+the+grsecurity%2FPaX+developers%2C+but+the+thieves+that+compelled+them+to+such+action...%0D%0A%0D%0A%5BI+hope+after+the+sad+news%5D+there+will+still+be+both%3A+the+grsecurity-hardening+in+Gentoo+%28and+Archlinux%29+remaining+as+the+best+--if+not+the+only+true--+option+for+security-aware+users+in+our+surveillance-infested+societies%2C+and%3A+there+will+be+a+way+to+spread+grsecurity+as+free+program+ever+more+in+the+*nix+world.%0D%0A%0D%0AFor+the+above+two+being+negatively+effected%2C+it+is+limitedly+so%3A+the+stable+grsecurity+not+anymore+published+doesn%27t+affect+many+people+like+me+at+all%3A+I+like+to+tinker+with+the+testing+sets+in+mostly+all+that+I+use%2C+build%2C+and+install+in+Gentoo.%0D%0A%0D%0AYou+can+see+the+%28possible%29+discussion+%28little+there+yet+at+the+time+of+this+writing%29+at%3A%0D%0A%0D%0ALINK+HERE%0D%0A%0D%0A%28the+current+title%29+grsecurity+withdrew+support+for+stable%3B+who+did+it+to+them%3F%0D%0Ahttps%3A%2F%2Fforums.gentoo.org%2Fviewtopic-t-1031476.html%0D%0A%0D%0AIf+I+learn+who+did+it%2C+I+won%27t+keep+it+to+myself%2C+but+I+won%27t+talk+about+it+here+in+grsecurity+forums%2C+but+there%2C+in+Gentoo+Forums.


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.
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia

Re: RBAC policy for tcpdump

Postby timbgo » Tue Oct 27, 2015 9:27 pm

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?).

Because:
Code: Select all
# export USE=suid ; emerge -p tcpdump

These are the packages that would be merged, in order:

Calculating dependencies    ... done!                       
[ebuild   R    ] net-analyzer/tcpdump-4.7.4-r1::gentoo  USE="drop-root ipv6 smi ssl suid* -libressl -samba {-test}" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB
#


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:
Code: Select all
# cat /proc/sys/kernel/grsecurity/exec_logging
1
# cat /proc/sys/kernel/grsecurity/audit_chdir
1
#


First, how the non-suid tcpdump fares in a normal user terminal.

No, first is what the [color=#000099]exec_logging[/coolor] and generally my system logs can tell me about the previously described tcpdump run.

This is excerpt from my system log (/var/log/messages) that correspond with when I started capturing with tcpdump and went to connect to forums.grsecurity.net for starting to post this topic.

Code: Select all
Oct 27 18:38:51 g0n kernel: [33265.003069] grsec: (admin:S:/) exec of /bin/date (date +%y%m%d_%H%M ) by /bin/date[bash:6796] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3335] uid/euid:0/0 gid/egid:0/0
Oct 27 18:38:51 g0n kernel: [33265.007502] grsec: (admin:S:/) exec of /bin/hostname (hostname ) by /bin/hostname[bash:6799] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3335] uid/euid:0/0 gid/egid:0/0
Oct 27 18:38:51 g0n kernel: [33265.009571] grsec: (admin:S:/) exec of /bin/touch (touch dump_151027_1838_g0n.pcap ) by /bin/touch[bash:6800] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3335] uid/euid:0/0 gid/egid:0/0
Oct 27 18:38:51 g0n kernel: [33265.010740] grsec: (admin:S:/) exec of /bin/chown (chown tcpdump:tcpdump dump_151027_1838_g0n.pcap ) by /bin/chown[bash:6801] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3335] uid/euid:0/0 gid/egid:0/0
Oct 27 18:38:51 g0n kernel: [33265.012342] grsec: (admin:S:/) exec of /bin/ls (ls --color=auto -l dump_151027_1838_g0n.pcap ) by /bin/ls[bash:6802] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3335] uid/euid:0/0 gid/egid:0/0
Oct 27 18:38:59 g0n kernel: [33273.662972] grsec: (miro:U:/) exec of /usr/bin/ffmpeg (ffmpeg -f x11grab -nostdin -loglevel 24 -s 1024x768 -r 25 -i :0.0 -c:v libx264 -preset ultrafast -threads 0 Screen_151027_1838_g) by /usr/bin/ffmpeg[bash:6803] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3688] uid/euid:1000/1000 gid/egid:1000/1000
Oct 27 18:39:01 g0n kernel: [33274.839243] grsec: (admin:S:/) exec of /usr/bin/sudo (sudo -s tcpdump -i any -w dump_151027_1838_g0n.pcap ) by /usr/bin/sudo[bash:6816] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3335] uid/euid:0/0 gid/egid:0/0
Oct 27 18:39:01 g0n sudo:     root : TTY=pts/8 ; PWD=/root ; USER=root ; COMMAND=/bin/bash -c tcpdump -i any -w dump_151027_1838_g0n.pcap
Oct 27 18:39:01 g0n kernel: [33274.843215] grsec: (admin:S:/) exec of /bin/bash (/bin/bash -c tcpdump -i any -w dump_151027_1838_g0n\.pcap ) by /bin/bash[sudo:6816] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3335] uid/euid:0/0 gid/egid:0/0
Oct 27 18:39:01 g0n kernel: [33274.845141] grsec: (admin:S:/) exec of /usr/sbin/tcpdump (tcpdump -i any -w dump_151027_1838_g0n.pcap ) by /usr/sbin/tcpdump[bash:6816] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3335] uid/euid:0/0 gid/egid:0/0
Oct 27 18:39:06 g0n dhcpcd[5652]: eth1: carrier acquired
Oct 27 18:39:06 g0n kernel: [33280.610137] 8139too 0000:04:06.0 eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
Oct 27 18:39:06 g0n kernel: [33280.611490] grsec: (admin:S:/) exec of /lib64/dhcpcd/dhcpcd-run-hooks (/lib/dhcpcd/dhcpcd-run-hooks ) by /lib64/dhcpcd/dhcpcd-run-hooks[dhcpcd:6817] uid/euid:0/0 gid/egid:0/0, parent /sbin/dhcpcd[dhcpcd:5652] uid/euid:0/0 gid/egid:0/0
Oct 27 18:39:06 g0n kernel: [33280.615339] grsec: (miro:U:/) exec of /usr/bin/dumpcap (/usr/bin/dumpcap -D -Z none ) by /usr/bin/dumpcap[wireshark:6818] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/wireshark[wireshark:5767] uid/euid:1000/1000 gid/egid:1000/1000
Oct 27 18:39:06 g0n dhcpcd[5652]: eth1: IAID 2e:f3:58:09
Oct 27 18:39:06 g0n kernel: [33280.625278] grsec: (miro:U:/) denied socket(netlink,raw,0) by /usr/bin/dumpcap[dumpcap:6818] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/wireshark[wireshark:5767] uid/euid:1000/1000 gid/egid:1000/1000
Oct 27 18:39:06 g0n kernel: [33280.643984] grsec: (miro:U:/) exec of /usr/bin/dumpcap (/usr/bin/dumpcap -D -Z none ) by /usr/bin/dumpcap[wireshark:6819] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/wireshark[wireshark:5767] uid/euid:1000/1000 gid/egid:1000/1000
Oct 27 18:39:06 g0n kernel: [33280.654875] grsec: (miro:U:/) denied socket(netlink,raw,0) by /usr/bin/dumpcap[dumpcap:6819] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/wireshark[wireshark:5767] uid/euid:1000/1000 gid/egid:1000/1000

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):

Code: Select all
# dumpfile=dump_$(date +%y%m%d_%H%M)_$(hostname).pcap ; \
   echo $dumpfile ; \
   touch $dumpfile ; \
   chown tcpdump:tcpdump $dumpfile ; \
   ls -l $dumpfile ; \
   read FAKE ; \
   sudo -s tcpdump -i any -w $dumpfile

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.

Code: Select all
$ dumpfile=dump_$(date +%y%m%d_%H%M)_$(hostname).pcap ; \
   echo $dumpfile ; \
   sodo -s touch $dumpfile ; \
   sudo -s chown tcpdump:tcpdump $dumpfile ; \
   ls -l $dumpfile ; \
   read FAKE ; \
   sudo -s tcpdump -i any -w $dumpfile


I pasted just the first 5 lines from the above that I prepares, and:

Code: Select all
Oct 28 01:26:10 g0n kernel: [57717.759986] grsec: (miro:U:/) exec of /bin/date (date +%y%m%d_%H%M ) by /bin/date[bash:7992] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3688] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:26:10 g0n kernel: [57717.764166] grsec: (miro:U:/bin/hostname) exec of /bin/hostname (hostname ) by /bin/hostname[bash:7995] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3688] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:26:10 g0n kernel: [57717.767626] grsec: (miro:U:/usr/bin/sudo) exec of /usr/bin/sudo (sudo -s chown tcpdump:tcpdump dump_151028_0126_g0n.pcap ) by /usr/bin/sudo[bash:7997] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3688] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:26:10 g0n kernel: [57717.786768] grsec: (root:U:/usr/bin/sudo) change to gid 0 denied for /usr/bin/sudo[sudo:7997] uid/euid:0/0 gid/egid:1000/1000, parent /bin/bash[bash:3688] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:26:10 g0n kernel: [57717.787934] grsec: (miro:U:/) exec of /bin/ls (ls --color=auto -l dump_151028_0126_g0n.pcap ) by /bin/ls[bash:7998] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3688] uid/euid:1000/1000 gid/egid:1000/1000


It's a similar issue that I haven't resoled with grsec, anyway, as just the next lines appear in the log while I was writing the draft of this text:

Code: Select all
Oct 28 01:30:01 g0n crond[7999]: setreuid failed: root 0
Oct 28 01:30:01 g0n crond[7999]: unable to ChangeUser (user root test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Oct 28 01:30:01 g0n crond[5131]: exit status 1 from user root test -x /usr/sbin/run-crons && /usr/sbin/run-crons
Oct 28 01:30:01 g0n kernel: [57948.925555] grsec: (root:U:/usr/sbin/crond) change to uid 0 denied for /usr/sbin/crond[crond:7999] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/crond[crond:5131] uid/euid:0/0 gid/egid:0/0


The bottom crond issue will relolve itself, as I know it does after I:

Code: Select all
# /etc/init.d/syslog-ng restart ; /etc/init.d/dcron restart ; /etc/init.d/postfix restart ;
 * Stopping syslog-ng ...                                                 [ ok ]
 * Checking your configfile (/etc/syslog-ng/syslog-ng.conf) ...           [ ok ]
 * Starting syslog-ng ...                                                 [ ok ]
 * Stopping dcron ...                                                     [ ok ]
 * Starting dcron ...                                                     [ ok ]
 * Stopping postfix  ...                                                  [ ok ]
 * Starting postfix  ...                                                  [ ok ]

(but I'll only see that normal every ten minutes run by dcron after some 5 more minutes, since that is a periodical 10 minutes activity of its).

But retrying the 5 lines for dumpcap, gave the same "...unable..." in the terminal and "...denied..." in the logs, result.

I'll try now and reinstall tcpdump with adding to /etc/portage/package.use:
Code: Select all
net-analyzer/tcpdump smi suid

(I see now that I had added the 'smi' use flag myself; must have been more than 10 days ago:
Code: Select all
 # ls -l /etc/portage/package.use
-rw-r--r-- 1 root root 5210 2015-09-17 08:30 /etc/portage/package.use
#


So pls. note how I only now recollect that the default for tcpdump install does not involve the smi use-flag, which is:
Code: Select all
# grep smi /usr/portage/profiles/use.* | grep tcpd
/usr/portage/profiles/use.local.desc:net-analyzer/tcpdump:smi - Build with net-libs/libsmi to load MIBs on the fly to decode SNMP packets
)

Aargh, but I have somehow, created another issue for myself, as I can see now, when I tried to open another uxrvt terminal from my openbox menu, and:
Code: Select all
miro@g0n ~ $ sudo -s
sudo: unable to change to root gid: Operation not permitted
sudo: unable to initialize policy plugin
miro@g0n ~ $


I haven't seen something like this yet, and really didn't expect something like this:
Code: Select all
Oct 28 01:40:01 g0n kernel: [58549.237198] grsec: (admin:S:/) exec of /bin/bash (/bin/sh -c test -x /usr/sbin/run-crons && /usr/sbin/run-crons ) by /bin/bash[crond:8252] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/crond[crond:8104] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.243702] grsec: (admin:S:/) exec of /usr/sbin/run-crons (/usr/sbin/run-crons ) by /usr/sbin/run-crons[sh:8255] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:8252] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.248713] grsec: (admin:S:/) exec of /bin/mkdir (mkdir -p /var/spool/cron/lastrun ) by /bin/mkdir[run-crons:8256] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.295895] grsec: (admin:S:/) chdir to /var by /bin/mkdir[mkdir:8256] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.295911] grsec: (admin:S:/) chdir to /var/spool by /bin/mkdir[mkdir:8256] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.295925] grsec: (admin:S:/) chdir to /var/spool/cron by /bin/mkdir[mkdir:8256] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.297758] grsec: (admin:S:/) exec of /bin/ln (ln -sn 8255 /var/spool/cron/lastrun/lock ) by /bin/ln[run-crons:8257] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.308299] grsec: (admin:S:/) exec of /usr/bin/find (find /var/spool/cron/lastrun -name cron.hourly -cmin +65 -exec rm {} ; ) by /usr/bin/find[run-crons:8258] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.311371] grsec: (admin:S:/) chdir to /root by /usr/bin/find[find:8259] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/find[find:8258] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.311563] grsec: (admin:S:/) exec of /bin/rm (rm /var/spool/cron/lastrun/cron.hourly ) by /bin/rm[find:8259] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/find[find:8258] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.312344] grsec: (admin:S:/) chdir to /root by /usr/bin/find[find:8258] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.313565] grsec: (admin:S:/) exec of /bin/touch (touch /var/spool/cron/lastrun/cron.hourly ) by /bin/touch[run-crons:8260] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.317071] grsec: (admin:S:/) exec of /usr/bin/find (find /var/spool/cron/lastrun -name cron.daily -cmin +1445 -exec rm {} ; ) by /usr/bin/find[run-crons:8261] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.318476] grsec: (admin:S:/) chdir to /root by /usr/bin/find[find:8261] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.319531] grsec: (admin:S:/) exec of /usr/bin/find (find /var/spool/cron/lastrun -name cron.weekly -cmin +10085 -exec rm {} ; ) by /usr/bin/find[run-crons:8262] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.320375] grsec: (admin:S:/) chdir to /root by /usr/bin/find[find:8262] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.321947] grsec: (admin:S:/) exec of /usr/bin/find (find /var/spool/cron/lastrun -name cron.monthly -cmin +44645 -exec rm {} ; ) by /usr/bin/find[run-crons:8263] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.322790] grsec: (admin:S:/) chdir to /root by /usr/bin/find[find:8263] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.323406] grsec: (admin:S:/) exec of /bin/touch (touch /var/spool/cron/lastrun ) by /bin/touch[run-crons:8264] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.324978] grsec: (admin:S:/) exec of /usr/bin/find (find /var/spool/cron/lastrun -newer /var/spool/cron/lastrun -exec /bin/rm -f {} ; ) by /usr/bin/find[run-crons:8265] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.325977] grsec: (admin:S:/) chdir to /root by /usr/bin/find[find:8265] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:01 g0n kernel: [58549.327106] grsec: (admin:S:/) exec of /bin/rm (rm -f /var/spool/cron/lastrun/lock ) by /bin/rm[run-crons:8266] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8255] uid/euid:0/0 gid/egid:0/0
Oct 28 01:40:25 g0n kernel: [58573.430331] grsec: (admin:S:/) exec of /bin/ls (ls --color=auto -ltr /etc/portage/package.use ) by /bin/ls[bash:8267] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3438] uid/euid:0/0 gid/egid:0/0
Oct 28 01:41:30 g0n kernel: [58638.512795] grsec: (root:U:/usr/bin/vim) denied create of /etc/portage/4913 for writing by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:41:30 g0n kernel: [58638.512888] grsec: (root:U:/usr/bin/vim) denied create of /etc/portage/package.use~ for writing by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:41:32 g0n kernel: [58640.114230] grsec: (admin:S:/) exec of /bin/ls (ls --color=auto -ltr /etc/portage/package.use ) by /bin/ls[bash:8272] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3438] uid/euid:0/0 gid/egid:0/0
Oct 28 01:42:39 g0n kernel: [58706.943731] grsec: (admin:S:/) exec of /bin/grep (grep --colour=auto smi /usr/portage/profiles/use.desc /usr/portage/profiles/use.local.desc ) by /bin/grep[bash:8273] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3438] uid/euid:0/0 gid/egid:0/0
Oct 28 01:42:43 g0n kernel: [58711.320343] grsec: (admin:S:/) exec of /bin/grep (grep --colour=auto smi /usr/portage/profiles/use.desc /usr/portage/profiles/use.local.desc ) by /bin/grep[bash:8276] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3438] uid/euid:0/0 gid/egid:0/0
Oct 28 01:42:43 g0n kernel: [58711.320412] grsec: (admin:S:/) exec of /bin/grep (grep --colour=auto tcpd ) by /bin/grep[bash:8277] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3438] uid/euid:0/0 gid/egid:0/0
Oct 28 01:45:09 g0n kernel: [58857.063449] grsec: (miro:U:/) exec of /usr/bin/urxvt (urxvt -fn 9x15bold,xft:Bitstream Vera Sans Mono ) by /usr/bin/urxvt[openbox:8278] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/openbox[openbox:3104] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.224385] grsec: (miro:U:/bin/bash) exec of /bin/bash (bash ) by /bin/bash[urxvt:8281] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/urxvt[urxvt:8278] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.233972] grsec: (miro:U:/) exec of /usr/bin/dircolors (dircolors -b /etc/DIR_COLORS ) by /usr/bin/dircolors[bash:8284] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:8283] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.250410] grsec: (miro:U:/) exec of /usr/bin/dircolors (dircolors -b /etc/DIR_COLORS ) by /usr/bin/dircolors[bash:8287] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:8286] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.254697] grsec: (miro:U:/) exec of /usr/bin/setxkbmap (setxkbmap gb ) by /usr/bin/setxkbmap[bash:8288] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:8281] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.284031] grsec: (miro:U:/bin/bash) exec of /bin/bash (sh -c "/usr/bin/xkbcomp" -w 1 "-R/usr/share/X11/xkb" -xkm "-" -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" -emp "> " ) by /bin/bash[X:8289] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/Xorg[X:3101] uid/euid:1000/0 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.291806] grsec: (miro:U:/) exec of /usr/bin/xkbcomp (/usr/bin/xkbcomp -w 1 -R/usr/share/X11/xkb -xkm - -em1 The XKEYBOARD keymap compiler (xkbcomp) reports: -emp >  -eml Errors from) by /usr/bin/xkbcomp[sh:8289] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/Xorg[X:3101] uid/euid:1000/0 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.308609] grsec: (miro:U:/) chdir to /usr/share/X11/xkb by /usr/bin/xkbcomp[xkbcomp:8289] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/Xorg[X:3101] uid/euid:1000/0 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.333204] grsec: (miro:U:/) exec of /usr/bin/xset (xset r rate 185 45 ) by /usr/bin/xset[bash:8290] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:8281] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.347290] grsec: (miro:U:/bin/hostname) exec of /bin/hostname (hostname ) by /bin/hostname[bash:8292] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:8291] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.348898] grsec: (miro:U:/) exec of /usr/bin/xrandr (xrandr --output VGA-0 --mode 1024x768 -s 75 ) by /usr/bin/xrandr[bash:8293] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:8281] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.421091] grsec: (miro:U:/bin/hostname) exec of /bin/hostname (hostname ) by /bin/hostname[bash:8295] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:8294] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.422923] grsec: (miro:U:/bin/hostname) exec of /bin/hostname (hostname ) by /bin/hostname[bash:8297] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:8296] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:45:09 g0n kernel: [58857.424563] grsec: (miro:U:/bin/hostname) exec of /bin/hostname (hostname ) by /bin/hostname[bash:8299] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:8298] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:45:30 g0n kernel: [58878.095482] grsec: (miro:U:/usr/bin/sudo) exec of /usr/bin/sudo (sudo -s ) by /usr/bin/sudo[bash:8300] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:8281] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:45:30 g0n kernel: [58878.102056] grsec: (root:U:/usr/bin/sudo) change to gid 0 denied for /usr/bin/sudo[sudo:8300] uid/euid:0/0 gid/egid:1000/1000, parent /bin/bash[bash:8281] uid/euid:1000/1000 gid/egid:1000/1000
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia

Re: RBAC policy for tcpdump

Postby timbgo » Tue Oct 27, 2015 9:34 pm

But I'm seeing something that seems to me is a buggy behavior.

It is not related directly with my topic, but I have to report it! And explain the circumstances related.
Code: Select all
Oct 28 01:45:30 g0n kernel: [58878.102056] grsec: (root:U:/usr/bin/sudo) change to gid 0 denied for /usr/bin/sudo[sudo:8300] uid/euid:0/0 gid/egid:1000/1000, parent /bin/bash[bash:8281] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:50:01 g0n kernel: [59149.667822] grsec: (admin:S:/) chdir to /root by /usr/sbin/crond[crond:8303] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/crond[crond:8104] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.668072] grsec: (admin:S:/) exec of /bin/bash (/bin/sh -c test -x /usr/sbin/run-crons && /usr/sbin/run-crons ) by /bin/bash[crond:8303] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/crond[crond:8104] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.674404] grsec: (admin:S:/) exec of /usr/sbin/run-crons (/usr/sbin/run-crons ) by /usr/sbin/run-crons[sh:8306] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:8303] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.680370] grsec: (admin:S:/) exec of /bin/mkdir (mkdir -p /var/spool/cron/lastrun ) by /bin/mkdir[run-crons:8307] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.680877] grsec: (admin:S:/) chdir to /var by /bin/mkdir[mkdir:8307] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.680888] grsec: (admin:S:/) chdir to /var/spool by /bin/mkdir[mkdir:8307] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.680896] grsec: (admin:S:/) chdir to /var/spool/cron by /bin/mkdir[mkdir:8307] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.682307] grsec: (admin:S:/) exec of /bin/ln (ln -sn 8306 /var/spool/cron/lastrun/lock ) by /bin/ln[run-crons:8308] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.684423] grsec: (admin:S:/) exec of /usr/bin/find (find /var/spool/cron/lastrun -name cron.hourly -cmin +65 -exec rm {} ; ) by /usr/bin/find[run-crons:8309] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.687037] grsec: (admin:S:/) chdir to /root by /usr/bin/find[find:8309] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.688439] grsec: (admin:S:/) exec of /usr/bin/find (find /var/spool/cron/lastrun -name cron.daily -cmin +1445 -exec rm {} ; ) by /usr/bin/find[run-crons:8310] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.690991] grsec: (admin:S:/) chdir to /root by /usr/bin/find[find:8310] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.692372] grsec: (admin:S:/) exec of /usr/bin/find (find /var/spool/cron/lastrun -name cron.weekly -cmin +10085 -exec rm {} ; ) by /usr/bin/find[run-crons:8311] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.694009] grsec: (admin:S:/) chdir to /root by /usr/bin/find[find:8311] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.694904] grsec: (admin:S:/) exec of /usr/bin/find (find /var/spool/cron/lastrun -name cron.monthly -cmin +44645 -exec rm {} ; ) by /usr/bin/find[run-crons:8312] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.697704] grsec: (admin:S:/) chdir to /root by /usr/bin/find[find:8312] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.698687] grsec: (admin:S:/) exec of /bin/touch (touch /var/spool/cron/lastrun ) by /bin/touch[run-crons:8313] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.699725] grsec: (admin:S:/) exec of /usr/bin/find (find /var/spool/cron/lastrun -newer /var/spool/cron/lastrun -exec /bin/rm -f {} ; ) by /usr/bin/find[run-crons:8314] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.700430] grsec: (admin:S:/) chdir to /root by /usr/bin/find[find:8314] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:01 g0n kernel: [59149.701023] grsec: (admin:S:/) exec of /bin/rm (rm -f /var/spool/cron/lastrun/lock ) by /bin/rm[run-crons:8315] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/run-crons[run-crons:8306] uid/euid:0/0 gid/egid:0/0
Oct 28 01:50:38 g0n kernel: [59186.156636] grsec: (miro:U:/usr/bin/vim) chdir to /Cmn/mr by /usr/bin/vim[vi:7783] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3124] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:50:38 g0n kernel: [59186.156676] grsec: (miro:U:/usr/bin/vim) chdir to /Cmn/mr by /usr/bin/vim[vi:7783] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3124] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:50:38 g0n kernel: [59186.156706] grsec: (miro:U:/usr/bin/vim) chdir to /Cmn/mr by /usr/bin/vim[vi:7783] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3124] uid/euid:1000/1000 gid/egid:1000/1000
Oct 28 01:52:56 g0n kernel: [59324.329116] grsec: (root:U:/usr/bin/vim) chdir to /root by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.329157] grsec: (root:U:/usr/bin/vim) chdir to /etc/portage by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.329189] grsec: (root:U:/usr/bin/vim) chdir to /root by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.329251] grsec: (root:U:/usr/bin/vim) chdir to /root by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.329277] grsec: (root:U:/usr/bin/vim) chdir to /etc/portage by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.329304] grsec: (root:U:/usr/bin/vim) chdir to /root by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.330085] grsec: (root:U:/usr/bin/vim) denied create of /etc/portage/.package.use.swp for reading writing by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.330153] grsec: (root:U:/usr/bin/vim) denied create of /etc/portage/.package.use.swp for reading writing by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.330278] grsec: (root:U:/usr/bin/vim) denied create of /var/tmp/package.use.swp for reading writing by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.330334] grsec: (root:U:/usr/bin/vim) denied create of /var/tmp/package.use.swp for reading writing by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.338501] grsec: (root:U:/usr/bin/vim) chdir to /root by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.338537] grsec: (root:U:/usr/bin/vim) chdir to /usr/share/vim/vim74 by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.338566] grsec: (root:U:/usr/bin/vim) chdir to /root by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.341798] grsec: (root:U:/usr/bin/vim) chdir to /root by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.341807] grsec: (root:U:/usr/bin/vim) chdir to /usr/share/vim/vimfiles/syntax by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.341815] grsec: (root:U:/usr/bin/vim) chdir to /root by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.341930] grsec: (root:U:/usr/bin/vim) chdir to /root by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.341938] grsec: (root:U:/usr/bin/vim) chdir to /usr/share/vim/vimfiles/syntax by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0
Oct 28 01:52:56 g0n kernel: [59324.341944] grsec: (root:U:/usr/bin/vim) chdir to /root by /usr/bin/vim[vi:3765] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3734] uid/euid:0/0 gid/egid:0/0


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:

Code: Select all
# grep RBAC /proc/$$/status
grep: /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.

But I'll add another (hopefully short) post for posting.
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia

Re: RBAC policy for tcpdump

Postby timbgo » Tue Oct 27, 2015 9:35 pm

What I got with the, basically current uncenz available from https://github.com/miroR/uncenz (the dumpcap-uncenz), is:
Code: Select all
miro@g0n /Cmn/mr $ uncenz-1st
g0n
151028_0219
151027_1533
sudo: unable to change to root gid: Operation not permitted
sudo: unable to initialize policy plugin
sudo: unable to change to root gid: Operation not permitted
sudo: unable to initialize policy plugin
sudo: unable to change to root gid: Operation not permitted
sudo: unable to initialize policy plugin
sudo: unable to change to root gid: Operation not permitted
sudo: unable to initialize policy plugin
$ffpid is:

$dupid is:

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...)...

Code: Select all
g0n ~ # dumpfile=dump_$(date +%y%m%d_%H%M)_$(hostname).pcap ; echo $dumpfile ; touch $dumpfile ; chown tcpdump:tcpdump $dumpfile ; ls -l $dumpfile ; read FAKE ; sudo -s tcpdump -i any -w $dumpfile
dump_151028_0223_g0n.pcap
-rw-r--r-- 1 tcpdump tcpdump 0 2015-10-28 02:23 dump_151028_0223_g0n.pcap

dropped privs to tcpdump
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes


and:

Code: Select all
miro@g0n /Cmn/mr $ ffmpeg -f x11grab -nostdin -loglevel 24 -s 1024x768 -r 25 -i :0.0 -c:v libx264 -preset ultrafast -threads 0 Screen_151028_0223_g0_g0n.mkv
No pixel format specified, yuv444p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.



I'll be trying...
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia

Re: RBAC policy for tcpdump

Postby timbgo » Sat Nov 07, 2015 9:36 am

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 know if I'll be able to correct that.

Regards!
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia

Re: RBAC policy for tcpdump

Postby jacekalex » Sun Nov 08, 2015 12:29 pm

I don't use RBAC, but I have to AppArmor profile:

Code: Select all
# Last Modified: Mon Jul 15 08:41:32 2014
#include <tunables/global>

/usr/sbin/tcpdump {
  #include <abstractions/base>
  #include <abstractions/nameservice>


    capability net_raw,
    capability net_admin,
    capability sys_chroot,
    capability dac_read_search,
    capability dac_override,
   
       /usr/sbin/tcpdump mr,

       @{PROC}/[0-9]*/net/dev          r,
        /proc/net/dev                  r,
             
       /usr/lib64/tls/x86_64/libcrypto.so*   mr,
       /usr/lib64/tls/libcrypto.so*   mr,
       /usr/lib64/x86_64/libcrypto.so*   mr,
       /usr/lib64/libcrypto.so*   mr,
       /usr/lib64/tls/libpcap.so*   mr,
       /usr/lib64/libpcap.so*   mr,
       /usr/lib64/tls/libc.so*   mr,
       /usr/lib64/libc.so*   mr,
       /etc/ld.so.cache   r,
       /lib64/libc.so*   mr,
       /lib64/libdl.so*   mr,
       /lib64/libz.so*   mr,
       /etc/localtime   mr,
       /var/lib/tcpdump  rwk,


}


Tcpdump works without suid/sgid:
Code: Select all
ls -l `which tcpdump`
-rwxr-x--- 1 root wireshark 1003000 10-24 07:43 /usr/sbin/tcpdump
getcap `which tcpdump`
/usr/sbin/tcpdump = cap_dac_read_search,cap_net_admin,cap_net_raw+ep


It may come in handy :)

Cheers
8)
jacekalex
 
Posts: 39
Joined: Tue Jan 11, 2011 2:16 pm
Location: Poland

Re: RBAC policy for tcpdump

Postby timbgo » Wed Nov 18, 2015 9:57 am

jacekalex wrote:I don't use RBAC, but I have to AppArmor profile:

Code: Select all
# Last Modified: Mon Jul 15 08:41:32 2014
#include <tunables/global>

/usr/sbin/tcpdump {
  #include <abstractions/base>
  #include <abstractions/nameservice>
...
}


Tcpdump works without suid/sgid:
Code: Select all
ls -l `which tcpdump`
-rwxr-x--- 1 root wireshark 1003000 10-24 07:43 /usr/sbin/tcpdump
getcap `which tcpdump`
/usr/sbin/tcpdump = cap_dac_read_search,cap_net_admin,cap_net_raw+ep


It may come in handy :)

Cheers
8)

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!
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia

Re: RBAC policy for tcpdump

Postby timbgo » Sun Jan 15, 2017 12:28 am

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.

You can do:

Code: Select all
$ git clone -b develop https://github.com/miroR/uncenz


or at a later time likely the default master branch:

Code: Select all
$ git clone https://github.com/miroR/uncenz


and see for yourself.

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).

So, let me see how I set the learning up...

Code: Select all
role root uG
role_transitions admin shutdown
role_allow_ip   192.168.22.0/24
role_allow_ip   192.168.23.0/24
role_allow_ip   0.0.0.0/32
user_transition_allow apache miro tcpdump
group_transition_allow apache miro tcpdump
# Role: root
subject /
    /
    /Cmn                r

[...]

# Role: root
subject /bin/bash o
   /            
   /Cmn            wc

   [...]

   /usr/local         r
   /usr/local/bin      rx
   /usr/sbin         x
   /usr/sbin/sendmail   rx
   /usr/sbin/tcpdump   x

[...]

# Role: root
subject /usr/sbin/tcpdump ol
user_transition_allow miro root nobody tcpdump
group_transition_allow miro root nobody tcpdump
   /            h
   -CAP_ALL
   bind   disabled
   connect   disabled

[...]

role tcpdump u
subject / ol
   /            h
   -CAP_ALL
   bind   disabled
   connect   disabled

# Role: tcpdump
subject /usr/sbin/tcpdump ol
user_transition_allow miro root nobody tcpdump
group_transition_allow miro root nobody tcpdump
   /            h
   -CAP_ALL
   bind   disabled
   connect   disabled

role miro u
role_allow_ip   0.0.0.0/32
# Role: miro
subject /
   /         h

   [...]

   /usr            
   /usr/bin         rx
   /usr/lib64         rx
   /usr/libexec         rx
   /usr/local         
   /usr/local/bin         rx
   /usr/sbin         h
   /usr/sbin/sendmail      rx
   /usr/sbin/tcpdump      x

# Role: miro
subject /bin/bash o
   /         h

   [...]

   /usr            
   /usr/bin         x
   /usr/bin/java      rx
   /usr/bin/mplayer   rx
   /usr/bin/mpv      rx
   /usr/bin/ssh      rx
   /usr/bin/xkbcomp   rx
   /usr/bin/urxvt         rx
   /usr/bin/tzap         rx
   /usr/lib64         rx
   /usr/libexec      rx
   /usr/local         
   /usr/local/bin         rwxc
   /usr/sbin         h
   /usr/sbin/sendmail      rx
   /usr/sbin/tcpdump      x



I gave a lot of the context for clarity. It's the:

Code: Select all
role tcpdump u
subject / ol


and the subject in it

Code: Select all
# Role: tcpdump
subject /usr/sbin/tcpdump ol


that are set up for learning, and also the subject

Code: Select all
# Role: root
subject /usr/sbin/tcpdump ol


in role root.

And before learning I added the tcpdump into

Code: Select all
user_transition_allow ... tcpdump
group_transition_allow ... tcpdump


into role root, into role root's tcpdump subject, and into role tcpdump's
tcpdump subject.

And I stuck

Code: Select all
   /usr/sbin/tcpdump      x


into role root's bash subject, into role miro /'s subject and into role miro bash's subject.

And I started the learning. For quite a lot of connections, to be on the safe side.

I'm not an expert really, so I'm not sure if any of that it superfluous or if something is still missing.

The thing is, what the GRADM learning produced, make it possible for me to use tcpdump to capture traffic with my uncenz program.

And this is what the learning got me:

Code: Select all
###  THE BELOW SUBJECT(S) SHOULD BE ADDED TO THE USER ROLE "tcpdump" ###
# Role: tcpdump
subject /usr/sbin/tcpdump o {
user_transition_allow miro root nobody tcpdump
group_transition_allow miro root nobody tcpdump

   /            h
   /Cmn            wc
   /etc            h
   /etc/host.conf         r
   /etc/hosts         r
   /etc/ld.so.cache      r
   /etc/resolv.conf      r
   /lib64            h
   /lib64/libnss_dns-2.23.so   rx
   /lib64/libresolv-2.23.so   rx
   /lib64/libresolv.so.2      
   /proc            r
   /proc/bus         h
   /proc/kallsyms         h
   /proc/kcore         h
   /proc/modules         h
   /proc/slabinfo         h
   /proc/sys         h
   /usr            h
   /usr/sbin/tcpdump      rx
   -CAP_ALL
   +CAP_DAC_OVERRIDE
   bind 0.0.0.0/32:0 dgram ip
   connect 127.0.0.1/32:53 dgram udp
}


###  THE BELOW SUBJECT(S) SHOULD BE ADDED TO THE USER ROLE "root" ###
# Role: root
subject /usr/sbin/tcpdump o {
user_transition_allow root tcpdump nobody miro
group_transition_allow root tcpdump nobody miro

   /            h
   /etc            h
   /etc/ld.so.cache      r
   /etc/localtime         r
   /etc/nsswitch.conf      r
   /etc/passwd         r
   /etc/services         r
   /lib64            rx
   /lib64/modules         h
   /proc            r
   /proc/bus         h
   /proc/kallsyms         h
   /proc/kcore         h
   /proc/modules         h
   /proc/slabinfo         h
   /sys            h
   /sys/class         h
   /sys/class/net         
   /sys/devices         h
   /sys/devices/pci0000:00      h
   /sys/devices/pci0000:00/0000:00:15.0/0000:05:00.0/net/eth0/ifindex   
   /sys/devices/pci0000:00/0000:00:15.1/0000:06:00.0/net/eth1/ifindex   
   /sys/devices/virtual      h
   /sys/devices/virtual/net/dummy0/ifindex   
   /sys/devices/virtual/net/lo/ifindex   
   /sys/devices/virtual/net/sit0/ifindex   
   /usr            h
   /usr/lib64         rx
   /usr/sbin         h
   /usr/sbin/tcpdump      rx
   -CAP_ALL
   +CAP_SETGID
   +CAP_SETUID
   +CAP_SETPCAP
   +CAP_NET_ADMIN
   +CAP_NET_RAW
   bind   disabled
   connect   disabled
   sock_allow_family unix inet netlink
}



And that is how I still have it applied in my /etc/grsec/policy and calling tcpdump from a script started as regular user, with sudo, works, as in my uncenz program.

I hope this helps an occasional newbie.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Try refute: rootkit hooks in kernel,
linux capabilities for intrusion? (Linus?)
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia

Re: RBAC policy for tcpdump

Postby timbgo » Wed Apr 05, 2017 12:07 pm

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

Regards!
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am
Location: Zagreb, Croatia


Return to RBAC policy development