RBAC policy for tcpdump
Posted: Tue Oct 27, 2015 1:48 pmtitle: 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.
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:
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:
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:
into:
(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:
I added:
and:
(at the right places so the policy is mostly alphabetically ordered)
I replaced:
with:
(see about 'nobody' the note further above)
and in that root sudo subject I also added:
Let me repeat here the main addition:
Another one of the non-necessary (but innocuous) changes, is in subject:
where I also added both:
and:
(see the proverbial note about 'nobody' further above; probably applies here too)
This:
I changed into:
and added the now proverbial:
(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:
and where the 'read FAKE' that you see in the line above, or let me expand it for you:
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:
into the command line issued as miro:
(in which the '151027_1828' I manually pasted in).
And then in the miro (the user's) terminal, when I hit Enter, I get:
(which is unimportant here, but it tells me ffmpeg is screencasting)
and in the root terminal, when I hit Enter, I get:
(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:
and:
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.
---
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.
