grsecurity forums

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?

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

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.

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

-Brad

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.

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 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?

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