There were 1 holes found in your RBAC configuration

Submit your RBAC policies or suggest policy improvements

There were 1 holes found in your RBAC configuration

Postby eRAZOR » Wed Dec 29, 2004 9:05 am

Hi

Invoking "gradm -E" on my server results in the following message:

"Write access is allowed by role backup0 to ., a directory which holds binaries for your system and is included in the PATH environment variable.

There were 1 holes found in your RBAC configuration. These must be fixed before the RBAC system will be allowed to be enabled."

The role in question is defined as:

Code: Select all
role backup0 u
subject /  {
        /                               h
        /bin                            h
        /bin/bash                       x
        /dev                            h
        /dev/tty                        rw
        /etc                            r
        /etc/ssh                        h
        /etc/grsec                      h
        /etc/shadow                     h
        /home                           r
        /lib                            rx
        /proc                           h
        /proc/meminfo                   r
        /usr                            h
        /usr/bin/rsync                  x
        -CAP_ALL
        bind    disabled
        connect disabled
}

Any ideas?
eRAZOR
 
Posts: 8
Joined: Wed Dec 29, 2004 9:03 am

Postby spender » Wed Dec 29, 2004 12:27 pm

Having . in your PATH is not a good idea. I'd need more information to figure out what the problem is. What was the full path of . when you enabled?

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby eRAZOR » Wed Dec 29, 2004 1:05 pm

Well, the non-priviledged user that initiated the SSH connection uses PATH=.:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin in .bashrc and elevated his privileges to root using su. In short root executed "gradm -E" while inheriting the environment of the original user.

User backup0 daily rsyncs the incremental backup results via ssh using his own private key from my home network. This user does not have PATH=.:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin set in .bashrc.
eRAZOR
 
Posts: 8
Joined: Wed Dec 29, 2004 9:03 am

Postby spender » Wed Dec 29, 2004 1:52 pm

I've fixed what I believe to be the problem in current CVS. The change was made to gradm_analyze.c.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby eRAZOR » Wed Dec 29, 2004 2:17 pm

spender wrote:I've fixed what I believe to be the problem in current CVS. The change was made to gradm_analyze.c.

-Brad


Going to try it tommorow. Just doing another full learning mode run since I believe activities during boot (iptables etc.) should be included in the learning session. Please correct me if I'm wrong.
eRAZOR
 
Posts: 8
Joined: Wed Dec 29, 2004 9:03 am

Postby spender » Wed Dec 29, 2004 2:59 pm

They shouldn't be, since you don't want that kind of activity to occur during normal operation of the system. Any administrative activities should be done through the admin role.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby eRAZOR » Wed Dec 29, 2004 3:16 pm

spender wrote:They shouldn't be, since you don't want that kind of activity to occur during normal operation of the system. Any administrative activities should be done through the admin role.

-Brad


But my firewall script containing iptables rules is executed at boot time by root. Active RBAC wont allow that or will it?
eRAZOR
 
Posts: 8
Joined: Wed Dec 29, 2004 9:03 am

Postby spender » Thu Dec 30, 2004 12:35 pm

Enable grsec after the script is run. The best way to do it would be to run an initial firewall script that blocks all incoming connection requests, then start all services, then run a second firewall script that allows connection requests to services you're running, and immediately enable the RBAC system after that script is run.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm


Return to RBAC policy development