Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

grsecurity: no data - no errors #58

Closed
cgzones opened this issue Apr 19, 2017 · 4 comments
Closed

grsecurity: no data - no errors #58

cgzones opened this issue Apr 19, 2017 · 4 comments

Comments

@cgzones
Copy link
Contributor

cgzones commented Apr 19, 2017

When using a grsecurity enhanced kernel and running vnstatd with the user vnstat, no data is collected.
Due to proc restrictions by grsec, the vnstat user must be a member of the grsec-proc group.

When this is not the case, vnstatd collects no data and produces no error or warning log messages.
Please add one for this case.

Maybe at

if ((fp=fopen(PROCNETDEV, "r"))!=NULL) {
and
if (readproc(inface)!=1) {
?

@vergoh
Copy link
Owner

vergoh commented Apr 22, 2017

I have access to one server using a grsecurity enhanced kernel. Looking at the content of /proc/net/dev, I really can't see any way to identify if the lack of traffic is caused by the interface actually having seen no traffic or by some masking by kernel related changes. Therefore, producing any warnings based on that data could result in false warnings.

Possibly a note to the non-root install instructions and the RESTRICTIONS section of the man page would be the correct place to include documentation related to this use scenario.

@cgzones
Copy link
Contributor Author

cgzones commented Apr 23, 2017

I misunderstood the problem at first, so the previous suggestions are void.

A note on the man page sounds good.

What about this patch

diff --git a/src/vnstatd.c b/src/vnstatd.c
index f42f562..4ef1440 100644
--- a/src/vnstatd.c
+++ b/src/vnstatd.c
@@ -162,6 +162,32 @@ int main(int argc, char *argv[])
        snprintf(errorstring, 512, "vnStat daemon %s started. (pid:%d uid:%d gid:%d)", getversion(), (int)getpid(), (int)getuid(), (int)getgid());
        printe(PT_Info);

+#if defined(__linux__)
+       /* grsecurity check, regarding /proc access */
+       {
+               const uid_t curr_euid = geteuid();
+               const struct group *grsec_grp = getgrnam("grsec-proc");
+
+               if (curr_euid != 0 && grsec_grp != NULL) {
+                       gid_t list[8];
+                       const int group_count = getgroups(8, list);
+                       if (group_count > 0) {
+                               int match = 0;
+                               for (int i = 0; i < group_count; ++i) {
+                                       if (list[i] == grsec_grp->gr_gid) {
+                                               match = 1;
+                                               break;
+                                       }
+                               }
+                               if (!match) {
+                                       snprintf(errorstring, 512, "grsecurity might block data collection, see man:vnstatd(1)");
+                                       printe(PT_Info);
+                               }
+                       }
+               }
+       }
+#endif
+
        /* main loop */
        while (s.running) {

@vergoh
Copy link
Owner

vergoh commented Apr 23, 2017

I'd prefer to have some way of detecting when a grsecurity enhanced kernel is being used. That way, the logic could be to check if the user is something else than root, then check for grsecurity and if found and traffic equals zero, show the warning.

The problem is, even after reading the grsecurity documentation, I haven't seen a way of detecting when grsecurity is enabled. The grsec-proc group at most indicates that the system may have had grsecurity enabled at some point. That group name may also be Debian specific as I didn't see such group name suggested by the grsecurity documentation directly.

@cgzones
Copy link
Contributor Author

cgzones commented May 4, 2017

Maybe for now an addition to the man page is sufficient, as adding detection for a running grsecurity enhanced kernel is not (meant to be?) simple and might invoke too extensive access (e.g. when using an LSM, like SELinux).
Also with the latest grsecurity announcement I do not know if and how grsecurity is shipped by distros in the future.

@vergoh vergoh closed this as completed in f8352f0 Mar 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants