gradm enforcing policy on non-existant file?

[tjh]

Hoping someone can help me with a problem I've started having ever since I edited my eggdrop's config file with vim and rehashed (forced it to reload it's config files) it.

Code: Select all

root@beaker:~# gradm -L /tmp/learn.log -E
root@beaker:~# gradm -a admin
Password:


RBAC is enabled. I've got a few other subjects in learning mode, thus the -L. GrSec starts erroring on /home/muppet/muppet/muppet.conf~:

Code: Select all

root@beaker:~# dmesg
grsec: From x.x.x.x: (root:U:/sbin/gradm) grsecurity 2.2.2 RBAC system loaded by /sbin/gradm[gradm:15215] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:15210] uid/euid:0/0 gid/egid:0/0
grsec: From x.x.x.x: (root:U:/sbin/gradm) successful change to special role admin (id 66) by /sbin/gradm[gradm:15218] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:15210] uid/euid:0/0 gid/egid:0/0
grsec: (muppet:U:/) denied bind() to 0.0.0.0 port 2001 sock type stream protocol tcp by /home/muppet/muppet/muppet.conf~[muppet.conf:1631] uid/euid:1014/1014 gid/egid:1014/1014, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: (muppet:U:/) denied bind() to 0.0.0.0 port 2001 sock type stream protocol tcp by /home/muppet/muppet/muppet.conf~[muppet.conf:1631] uid/euid:1014/1014 gid/egid:1014/1014, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: (muppet:U:/) denied bind() to 0.0.0.0 port 2001 sock type stream protocol tcp by /home/muppet/muppet/muppet.conf~[muppet.conf:1631] uid/euid:1014/1014 gid/egid:1014/1014, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: (muppet:U:/) denied bind() to 0.0.0.0 port 2001 sock type stream protocol tcp by /home/muppet/muppet/muppet.conf~[muppet.conf:1631] uid/euid:1014/1014 gid/egid:1014/1014, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: (muppet:U:/) denied bind() to 0.0.0.0 port 2001 sock type stream protocol tcp by /home/muppet/muppet/muppet.conf~[muppet.conf:1631] uid/euid:1014/1014 gid/egid:1014/1014, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: (muppet:U:/) denied bind() to 0.0.0.0 port 2001 sock type stream protocol tcp by /home/muppet/muppet/muppet.conf~[muppet.conf:1631] uid/euid:1014/1014 gid/egid:1014/1014, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
grsec: more alerts, logging disabled for 10 seconds


Disable RBAC system, examine erroring file:

Code: Select all

root@beaker:~# gradm -D
Password:
root@beaker:~# ls -la /home/muppet/muppet/muppet.conf~
ls: cannot access /home/muppet/muppet/muppet.conf~: No such file or directory


But the file doesn't exist!

I do have a policy for

Code: Select all

/home/muppet/muppet/muppet.conf

#role: muppet
subject /home/muppet/muppet/muppet.conf o {
        /                               h
        /bin                            h
        /bin/chmod                      x
        /bin/cp                         x
        /bin/ls                         x
        /dev
        /dev/grsec                      h
        /dev/kmem                       h
        /dev/log                        h
        /dev/mem                        h
        /dev/null                       rw
        /dev/port                       h
        /etc                            r
        /etc/grsec                      h
        /etc/gshadow                    h
        /etc/gshadow-                   h
        /etc/ppp                        h
        /etc/samba/smbpasswd            h
        /etc/shadow                     h
        /etc/shadow-                    h
        /etc/ssh                        h
        /home
        /home/muppet                    rxwcd
        /lib                            rx
        /lib/modules                    h
        /tmp                            rwcd
        /usr
        /usr/lib                        rx
        /usr/local
        /usr/share                      r
        /usr/src                        h
        -CAP_ALL
        bind 0.0.0.0/32:2001 stream dgram ip tcp
        bind 0.0.0.0/32:0 stream dgram ip tcp
        connect 0.0.0.0/0:113 stream tcp
        connect 0.0.0.0/0:1025-65535 stream tcp
        connect 58.28.6.2/32:53 dgram udp
        connect 58.28.4.2/32:53 dgram udp
}


which is what usually works. So I'm a little confused how grsec is getting hits from a file that no longer exists. I guess there would have been a muppet.conf~ when I was editing the file with vim, isn't ~ what vim appends to filenames when it's working with them? How can it be triggering now on the file that doesn't exist though?

I could probably work around this using a muppet.conf* in the policy, but I'd rather understand how I've got into this situation.

Thanks!

Kernel is

Code: Select all

Linux beaker 3.0.8-grsec #1 SMP Wed Oct 26 10:50:36 NZDT 2011 i686 GNU/Linux

so the version of grsec would have been whatever one was the latest on the 26th Oct 2011.

[spender]

Was the eggdrop already running when you enabled RBAC? It must have been running with the rename'd ~ name (which you could also see via /proc/pid/exe) since you just rehashed it instead of restarting it.

-Brad

[tjh]

The eggdrop was already running, yea. It had been running just fine for some time. All I did was disable the RBAC system while I make some changes to it's scripts (added another one to the muppet.conf file) and then rehashed it and re-enabled the RBAC system. I'd never, as best I know, been run using a ~

Code: Select all

root@beaker:/proc# ps aufx | grep mupp
muppet    1631  0.0  1.4  21184 14836 ?        S    Oct26  10:30 /home/muppet/muppet/eggdrop ./muppet.conf
root     20708  0.0  0.0   3368   768 pts/3    S+   10:52   0:00              \_ grep mupp
root@beaker:/proc# cd 1631
root@beaker:/proc/1631# ls
auxv     comm  environ  fd      ipaddr  maps  mountinfo  mountstats  ns       oom_score      personality  stat   status
cmdline  cwd   exe      fdinfo  limits  mem   mounts     net         oom_adj  oom_score_adj  root         statm  task
root@beaker:/proc/1631# cat cmdline
/home/muppet/muppet/eggdrop./muppet.confroot@beaker:/proc/1631#


[spender]

Don't look at cmdline, look at the /proc/pid/exe symlink.

-Brad

[tjh]

Sorry my bad.

The exe symlink points to

Code: Select all

/home/muppet/muppet/eggdrop-1.6.20


That was installed the day the eggdrop was and hasn't been modified recently.

Tim

[spender]

So I think the conf file is used as an interpreter (contains #!/path/to/eggdrop), and because this original file was renamed, that's why we printed it out what was displayed. For interpreted scripts, when executed directly, we use the path of the script as the "binary" instead of the generic interpreter.

-Brad

[tjh]

Yes the config file is, it kicks off the eggdrop:

Code: Select all

#! /home/muppet/muppet/eggdrop
# ^- This should contain a fully qualified path to your Eggdrop executable.


Code: Select all

oot@beaker:/home/muppet/muppet# ls -la eggdrop
lrwxrwxrwx 1 muppet muppet 14 Sep  9 10:14 eggdrop -> eggdrop-1.6.20


How do I fix the root problem of grsec denying things based on this new filename? My subject for muppet.conf allows the behavior that muppet.conf~ is attempting to do and being denied. Should I just modify the subject to be muppet.conf* ?

Tim

[tjh]

I guess what I'm really struggling to understand is, where is muppet.conf~ coming from?

I've looked at my vim setup - none of the edits I did would have created a conf~ file. I've even strace'd the eggdrop when I reload it. It's PID doesn't change. I can see nowhere that it renames the .conf to .conf~before parsing it.

I can easily work around the problem using a wildcard in my subject. But that annoys me, because I don't understand why I have to do that, only that I do

Thanks!

Tim

[spender]

Wildcards aren't supported for subjects -- it's still on the TODO list.

-Brad