Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
SELinux violations for /etc/init.d/sysfs
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
vnd
n00b
n00b


Joined: 28 Jan 2011
Posts: 19

PostPosted: Sun Jul 05, 2015 11:57 am    Post subject: SELinux violations for /etc/init.d/sysfs Reply with quote

Hi

I've experienced quite an unusual errors last week. Just after the installation of the fresh system running on latest hardened-sources 3.18.9 with SELinux enabled I was able to see the following avc violation and the crash after it:
Code:
[   12.079311][   12.104693] audit: type=1400 audit(1436059229.076:6): avc:  denied  { write } for  pid=2281 comm="cgroup-release-" name="full" dev="devtmpfs" ino=1029 scontext=system_u:system_r:openrc_cgroup_release_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0
[   12.104768] traps: cgroup-release-[2281] general protection ip:3209f735e10 sp:3dd065f1b40 error:0 in ld-2.20.so[3209f71d000+22000]
[   12.104778] grsec: Segmentation fault occurred at            (nil) in /lib64/rc/sh/cgroup-release-agent.sh[cgroup-release-:2281] uid/euid:0/0 gid/egid:0/0, parent /[kworker/u16:1:41] uid/euid:0/0 gid/egid:0/0
[   12.104845] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /lib64/rc/sh/cgroup-release-agent.sh[cgroup-release-:2281] uid/euid:0/0 gid/egid:0/0, parent /[kworker/u16:1:41] uid/euid:0/0 gid/egid:0/0

These logs comes from service /etc/init.d/sysfs being run, and more exactly from function mount_cgroups that sets "/lib64/rc/sh/cgroup-release-agent.sh" as a release agent in mount command. To debug the problem I've set type openrc_cgroup_release_t as permissive and after that I was able to see more things that would be blocked - as expected in this case there's no crash:
Code:
[   17.964543] audit: type=1400 audit(1436102058.933:6): avc:  denied  { write } for  pid=2276 comm="cgroup-release-" name="full" dev="devtmpfs" ino=1030 scontext=system_u:system_r:openrc_cgroup_release_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1
[   17.964621] audit: type=1400 audit(1436102058.933:7): avc:  denied  { open } for  pid=2276 comm="cgroup-release-" path="/dev/full" dev="devtmpfs" ino=1030 scontext=system_u:system_r:openrc_cgroup_release_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1
[   17.964703] audit: type=1400 audit(1436102058.933:8): avc:  denied  { getattr } for  pid=2276 comm="cgroup-release-" path="/dev/full" dev="devtmpfs" ino=1030 scontext=system_u:system_r:openrc_cgroup_release_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1
[   17.964802] audit: type=1400 audit(1436102058.933:9): avc:  denied  { read } for  pid=2276 comm="cgroup-release-" name="null" dev="devtmpfs" ino=1028 scontext=system_u:system_r:openrc_cgroup_release_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1

Going deep I was trying to localize the point of a problem but I've stuck a little bit :? Maybe you would help - the entry point to type openrc_cgroup_release_t is shell file /lib64/rc/sh/cgroup-release-agent.sh:
Code:
-rwxr-xr-x. 1 root root staff_u:object_r:openrc_cgroup_release_exec_t:s0 8.0K Jul  5 03:00 /lib64/rc/sh/cgroup-release-agent.sh

So my first thought was that it's because of /bin/sh that under the hood tries to write to /dev/full and /dev/null - as the avc logs suggest - and I was even sure about it because removing this file "solves" the problem with policy violations. But anyway it's just workaround that deleting this file might cause some misbehavious... I've tried to replace original shell script:
Code:
#!/bin/sh
#
# This is run by the kernel after the last task is removed from a
# control group in the openrc hierarchy.

cgroup=/sys/fs/cgroup/openrc
PATH=/bin:/usr/bin:/sbin:/usr/sbin
if [ -d ${cgroup}/"$1" ]; then
        rmdir ${cgroup}/"$1"
fi

with C version like this:
Code:
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[]) {

        const char path[] = "/sys/fs/cgroup/openrc/";
        char *new_path;
        unsigned long length;
        struct stat s = {0};


        if (argc > 1) {

                unsigned long length = strlen(argv[1]);
                new_path = malloc(sizeof(path) + length);

                if (new_path == 0) {
                        return EXIT_FAILURE;
                }
                strcpy(new_path, path);
                strcat(new_path, argv[1]);

                if (stat(new_path, &s)) {
                        free(new_path);
                        return EXIT_FAILURE;
                }
                if (!(s.st_mode & S_IFDIR)) {
                        free(new_path);
                        return EXIT_SUCCESS;
                }
                if (rmdir(new_path)) {
                        free(new_path);
                        return EXIT_FAILURE;
                }

        }
        return EXIT_SUCCESS;
}

but to my surprise the policy violations remains the same :( do you have any idea what could cause io actions on these /dev devices? The step lower is glibc but it's quite unreal for me that the problem lies there.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum