grsecurity forums

Hi,

i got a little problem to create an acl by learning mode for snort. After i included the neu learned acl and restarted snort i got the following error in the syslog:

kernel: grsec: attempted socket(2,2,0) by (snort:839) UID(0) EUID(0), parent (snort:838) UID(0) EUID(0)

And in the daemon.log i found this:

snort: socket:Permission denied
snort: FATAL ERROR: ERROR: Can not get MTU of an interface ppp0!

I'm using the default acl as described in Grsecurity Acl Documentation und this snort-acl:

/usr/sbin/snort o {
/ h
/usr/sbin/snort x
/dev/log
/dev/null rw
/etc r
/etc/ld.so.cache rx
/etc/snort r
/lib/ld-2.2.5.so x
/lib rx
/usr/lib/i586/libcrypto.so.0.9.6 rx
/usr/lib/i586/libssl.so.0.9.6 rx
/usr/lib rx
/usr/share/mysql/charsets/Index r
/usr/share/zoneinfo/Europe/Berlin r
/var/log/snort w
/var/log/snort/portscan.log ra
/var/run w
/var/run/mysqld/mysqld.sock
/var/run/snort_ppp0.pid w
-CAP_ALL
+CAP_DAC_OVERRIDE
+CAP_SETGID
+CAP_SETUID
+CAP_NET_RAW
RES_FSIZE 50024 50024
RES_DATA 7010064 7010064
RES_STACK 29672 29672
RES_RSS 0 0
RES_NPROC 41 41
RES_NOFILE 13 8
RES_MEMLOCK 0 0
RES_AS 16040224 16040224
RES_LOCKS 0 0

connect {
disabled
}

bind {
disabled
}

}

Maybe someone has an idea how i can solve this problem?

moony

what version of grsecurity are you using? It should have learned that access, since it was for AF_INET, SOCK_DGRAM. Could you look through your learned logs for snort and try to find some lines with ip addresses in them? Those would be the learned ip acls. It would help to find if this problem was in userspace or the kernel.

-Brad

Hi spender

i'm using the grsecurity-1.9.7d-2.4.19-Patch.

I greped trought the syslog for LEARN-Matches but there is no Match which contains an IP-Address. But i found 512 matches like
kernel: grsec: LEARN:773:31152:771:26398:/etc/protocols:16
kernel: grsec: LEARN:773:31152:771:26398:/etc/protocols:1
It seems that snort is seeking something in /etc/protocols
In learning mode snort works fine, but if i use the learned rules it aborts on startup. I'm running snort on a ADSL-ppp0-Interface and it logs all alerts to a local mysql database.

moony

hmmm....apparently snort doesn't use bind or connect. So the IP ACLs won't apply for it. Just remove the connect{} and bind{} rules in your ACL.

-Brad

It works

but what i don't understand...
if snort has no need for connect() and bind(), why it doesn't work with connect { disabled } and bind { disabled } ?

Tnx for your help, spender

because ACLs for socket() are created based on the rules for connect and bind. It seems this needs to be changed.

-Brad

What if for example ld-2.2.5.so got updated to another version? Would cost alot of work to update the ACL's.

so you give rx to /lib...doesn't really hurt anything. Most text editors have search/replace capability....2 commands shouldn't be too hard to execute.

-Brad

or put the acl on the symlink to which ld-2.2.5.so is referenced. Then all you need to do is reload the ACL system.

-Brad

On some systems (running CVS/unstable versions) that could mean a lot of work.

spender wrote:or put the acl on the symlink to which ld-2.2.5.so is referenced. Then all you need to do is reload the ACL system.

Yeah i thought about that but i thought that could be a little bit dangerous because one could change the symlink to something else if they had root. But then again, they would already have root.

nope. Grsecurity will never place an ACL on a symlink. It puts the ACL on the file the symlink references. And since /lib is enforced with no writing, it's impossible to modify that symlink. Having root makes no difference. Also, let's assume that some process was able to modify that symlink (for some crazy reason, someone gave /lib write access in a subject other than that for /)...best case scenario for the attacker, they are also given a shell, with access to tools that they can use to copy in their trojaned library into a location that is not allowed to be written to with the default ACL. They could then cause everyone to execute their modified code and leak privileges...etc. The worst case scenario for the attacker, and the much more probable case, is that they have to use a shell account on the system, that is unprivileged, and they would write their library into a location they can write to. The mmap restrictions built into grsecurity would prevent anyone from executing this trojaned library.

-Brad

Wow that's incredible. But i don't understand something about the story: you say /lib is enforced with no writing. That means only the files which already exist? Or no writing to /lib at all? If i read the words literally and readed the xamples in your docs i'd say no writing at /lib at all.

Because if i do apt-get dist-upgrade and a security patch _or_ new program is to be installed using /lib, will both not work? Or is your argument against this that it is not needed to patch software anymore with proper GrSecurity ACL?

no writing to /lib at all.

-Brad

That would kinda break Debian + APT. What Linux distribution do you advise in combination with GrSecurity?

You see, i'm setting up a free shell provider and the features GrSec give are far more then OpenBSD would give me. So my choice is Linux. But then again i'm Debian (stable) fan and this would break APT pretty much.

If you need to update/install packages, you should do so in admin mode. This allows you to do what you need, while not having to disable the ACL system.

-Brad