CAP_NET_ADMIN Broken ?

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

CAP_NET_ADMIN Broken ?

Postby Debiant » Thu Feb 06, 2003 1:00 pm

Hi,

I'm currently writing my very first set of ACL's for LIVE deployment on webservers and database boxes. Hooray !! Maybe now I can get some sleep at night.

Here's the problem:
I am removing the NET_ADMIN capability from the default ACL., it prevents me from bringing up a new interface or adding an alias, however I can still bring down an interface and/or add/remove routes ? GRSec tells me that CAP_NET_ADMIN is denied, but the end result is either a unreachable network or a new route.

I'm running 2.4.20 from kernel.org with the GRS 1.9.8.
Its running on a very basic RedHat 8.0 install.

Any help would be greatly appreciated.
Debiant
 
Posts: 6
Joined: Thu Feb 06, 2003 12:35 pm

Postby spender » Thu Feb 06, 2003 3:05 pm

I don't believe this is a grsecurity problem, as the capability code is correct. I've just tested your situation on my system here with no problems:

www:/etc/grsec# gradm -E
www:/etc/grsec# ifconfig eth0 down
SIOCSIFFLAGS: Permission denied
www:/etc/grsec# route add 192.168.2.0
SIOCADDRT: Operation not permitted
www:/etc/grsec# gradm -D
Password:
www:/etc/grsec# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

notice no .2.0 entry

www:/etc/grsec# ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:5A:D1:70:75
....

notice eth0 is still up

and in the logs:

grsec: use of CAP_NET_ADMIN denied for (ifconfig:11301) UID(0) EUID(0), parent (bash:11285) UID(0) EUID(0)

grsec: use of CAP_NET_ADMIN denied for (route:11307) UID(0) EUID(0), parent (bash:11285) UID(0) EUID(0)

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

Postby spender » Thu Feb 06, 2003 3:12 pm

Also, as more proof, here's a snippet of code from net/ipv4/fib_frontend.c:

int ip_rt_ioctl(unsigned int cmd, void *arg)
{
int err;
struct kern_rta rta;
struct rtentry r;
struct {
struct nlmsghdr nlh;
struct rtmsg rtm;
} req;

switch (cmd) {
case SIOCADDRT: /* Add a route */
case SIOCDELRT: /* Delete a route */
if (!capable(CAP_NET_ADMIN))
return -EPERM;

If you did indeed remove the CAP_NET_ADMIN capability a subject that covered /sbin/route, then it would have denied it right there.

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

Postby Debiant » Fri Feb 07, 2003 5:38 am

Thanks for taking the time to check and reply.

I have run the same test you have run and I get denied in exactly the same way.
However if I use /sbin/ip to add/delete routes I can do so without any errors or warnings.

[root@~ moya]# ip route add 192.168.50.2 via 192.168.10.2 dev eth0
[root@~ moya]# netstat -rn
Kernel IP routing table
Destination       Gateway    Genmask    Flags    MSS Window    irtt     Iface
192.168.50.2     192.168.10.2     255.255.255.255     UGH     40     0     0     eth0
192.168.10.0     0.0.0.0     255.255.255.0     U     40     0     0     eth0
127.0.0.0           0.0.0.0     255.0.0.0     U     40     0     0     lo
0.0.0.0           192.168.10.1     0.0.0.0     UG     40     0     0     eth0
[root@~ moya]# telnet 192.168.50.2 22
Trying 192.168.50.2...
Connected to 192.168.50.2
Escape character is '^]'.
OpenSSH 3.5p1

Protocol mismatch.
Connection closed by foreign host.
[root@~ moya]#

I was wrong when I said I could bring the interface down though. I can not do that, but I can unbind its IP address and remove the interface from the routing table.

Remove all the routing information for the interface: ip addr flush dev eth0
Unbind the ip address from the interafce: ip addr delete 192.168.10.10 dev eth0
Bind a new / different IP address: ip addr add 192.168.10.40 dev eth0

How is this possible ?
Debiant
 
Posts: 6
Joined: Thu Feb 06, 2003 12:35 pm

Postby spender » Fri Feb 07, 2003 8:37 am

strace it while it's doing those commands, and paste the results in here.
eg.
strace ip addr delete 192.168.10.10 dev eth0 2> /root/log


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

Feeling queesy now

Postby Debiant » Fri Feb 07, 2003 10:13 am

The more I look into this more uneasy I feel. :(

I have straced the ip command and it appears to use netlink sockets PF_NETLINK to talk to the kernel directly. man (7) netlink. Obviously this is bypassing the capability system and allows root the ability to contol parts of the network he shouldn't be allowed to.

I wouldn't be incredibly suprised if /sbin/tc did the same thing. I'm doing some more investigation and I will post the strace info as soon as I finish.
Debiant
 
Posts: 6
Joined: Thu Feb 06, 2003 12:35 pm

Postby spender » Fri Feb 07, 2003 10:43 am

Ah, you need to have CAP_NET_RAW removed as well. I thought this was removed in the default ACL?

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

Postby Debiant » Fri Feb 07, 2003 10:51 am

It is removed in the default ACL and in mine.

-CAP_LINUX_IMMUTABLE
-CAP_NET_RAW
-CAP_MKNOD
-CAP_SYS_RAWIO
-CAP_SYS_MODULE
-CAP_SYS_ADMIN
-CAP_SYS_PTRACE
-CAP_NET_ADMIN
Debiant
 
Posts: 6
Joined: Thu Feb 06, 2003 12:35 pm

Postby spender » Fri Feb 07, 2003 4:14 pm

Ok, i've just added rtnetlink support to grsecurity, so it works correctly now. The code is in current CVS. I'll be releasing 1.9.9 final that will include this change.

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

Excellent

Postby Debiant » Fri Feb 07, 2003 5:11 pm

Hi Brad,

Thats great. Most excellent.
Thank you for your work on this, and thanks to the whole team for grsecurity.
It is an excellent and invaluable project.

Thank you.

Maybe you should send a notificication post about this to bugtrack ???

Thanks again,

Mark
Debiant
 
Posts: 6
Joined: Thu Feb 06, 2003 12:35 pm


Return to grsecurity support