grsecurity forums

It seems that an object like "/home/users/*/logs" is not correctly understood by gradm2. It's cutting everything after the *, and then the resulting object is "/home/users/*".

I tested with :

Code: Select all

/home/users           rwlcdx
/home/users/*/logs       r

This denies access in write or create to any file in /home/users/boo/, whereas it should allow only read in /home/users/boo/logs and full access in the remaining part of /home/users/boo.

PS: I'm using latest grsec and gradm (v2.1.0) + kernel 2.4.28 + secfixes

/home/users is basically the same thing as /home/users/* (except /home/users matches the directory /home/users also). Any file within /home/users that isn't matched by any more specific rule will match /home/users.

-Brad

Yeah I know, but maybe I was not clear :p. I'll try to explain correctly :

I want to give only read access to all directories in "/home/users/*/logs", but to give full access to the rest of the home dirs. Since I put apache logs into the homedirs, I don't want users to be even able to remove them or link them to /etc/passwd... in case of failure of the DAC system.

That's why I wanted to put 2 objects in default subject :

Code: Select all

subject / {
   ....
   /home/users           rwlcdx
   /home/users/*/logs    r
}

But it seems gradm reads this juste like the /home/users/*/logs was /home/users/*. Isn't there a misbehavior ?

Can you try the 2.1.1 patch from http://grsecurity.net/~spender?

I believe this problem is resolved there.

-Brad

Thanks, but if you don't mind, I'll use the 2.1.1 when it'll be released. I cannot use prepatches on a prod server...

It seems there is another globbing issue. The kernel is Hardened Gentoo's hardened-sources-2.6.28-r6.

Code: Select all

role testrole s
subject /
/ rwxaimcdl
/proc r
/proc/cpuinfo r
/proc/loadavg r
/proc/meminfo r
/proc/self r
/proc/stat r
/proc/uptime r
/proc/version r
/proc/a* h
/proc/b* h
/proc/c* h
/proc/d* h
/proc/e* h
/proc/f* h
/proc/g* h
/proc/h* h
/proc/i* h
/proc/j* h
/proc/k* h
/proc/l* h
/proc/m* h
/proc/n* h
/proc/o* h
/proc/p* h
/proc/q* h
/proc/r* h
/proc/s* h
/proc/t* h
/proc/u* h
/proc/v* h
/proc/w* h
/proc/x* h
/proc/y* h
/proc/z* h
/proc/*/cmdline r
/proc/*/coredump_filter rw
/proc/*/cwd r
/proc/*/environ r
/proc/*/exe r
/proc/*/fd r
/proc/*/fdinfo r
/proc/*/ipaddr r
/proc/*/limits r
/proc/*/loginuid r
/proc/*/root r
/proc/*/sessionid r
/proc/*/stat r
/proc/*/statm r
/proc/*/status r
/proc/*/task r
/proc/*/task/*/cmdline r
/proc/*/task/*/cwd r
/proc/*/task/*/environ r
/proc/*/task/*/exe r
/proc/*/task/*/fd r
/proc/*/task/*/fdinfo r
/proc/*/task/*/limits r
/proc/*/task/*/loginuid r
/proc/*/task/*/root r
/proc/*/task/*/sessionid r
/proc/*/task/*/stat r
/proc/*/task/*/statm r
/proc/*/task/*/status r
[b]/proc/*/task/*/* h[/b]
/proc/*/* h


With this ruleset all files in /proc/<pid>/task/<pid>/ are viewable by ls(1) as directory entries (that's the issue), but some of them still cannot be read according the policy (and that's correct). So, I found no way to restrict directory listings with paths containing two or more wildcard characters. Is this a bug?

I'm looking into this right now, and should have an answer for you shortly.

In case it might help others, I'm going to describe how globbed matching is implemented and how the system decides which rule to use for matching.

The globbing system does support multiple wildcard characters.
Globbed objects are "anchored" to non-globbed objects, which are generally matched by their inode/device pair.
The anchor point is determined by finding the most specific directory within the path that is fixed, for example:
If the globbed object is /home/*/blah, the anchor point is /home
If the globbed object is /home/test/*/hi/*/blah, the anchor point is /home/test
If multiple globbed objects are anchored to the same non-globbed object, they are ordered by the number of path components present in the object, so:
where /home/*/test/* and /home/* are both anchored to /home, /home/*/test/* is checked first, since it has 4 path components, while /home/* has 2.
If two globbed objects anchored to the same non-globbed object have the same number of path components, then the first object listed in your policy is the one that is checked first.

Here''s scenario to illustrate how the matching decision is made:

Suppose your policy is the following:

/home
/home/test/blah r
/home/* h

If you're opening /home/test/blah2 for reading, the system will perform the following checks:
1) does an inode/device-based object exist for /home/test/blah2 ?
2) there does not, so does an inode/device-based object exist for /home/test?
3) there does not, so does an inode/device-based object exist for /home?
4) there does. Does the inode/device-based object for /home have any anchored globbed objects?
5) it does, so iterate through the list and perform the globbed matching
6) /home/* matches /home/test/blah2, so the file is considered hidden and reading it is disallowed

-Brad

I've discovered the problem and am writing up a patch (for 2.4 and 2.6) now. As you've experienced, the problem is purely with readdir, the files hidden by the rules are only visible in a directory listing but can't be stat'd or read or accessed in any other way. It also only manifests itself when globbing characters are used in multiple path components.

-Brad

The patches are now online in http://grsecurity.net/~spender/. It should resolve your problem, let me know if it does not.

-Brad

Yes, the problem is gone now. Thank you!

Hmm... I experience another bug that looks similar, but it's not a globbing issue. Here is kind of self-descriptive console listing:

Code: Select all

hardened-server j_192-168-0-150 # gradm -v
gradm v2.1.14
Licensed under the GNU General Public License (GPL) version 2 or higher
Copyright 2002,2003,2004  Brad Spengler
hardened-server j_192-168-0-150 # uname -a
Linux hardened-server 2.6.29.1-grsec-grjail #2 SMP Sat Apr 11 16:35:23 KRAST 2009 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ AuthenticAMD GNU/Linux
hardened-server j_192-168-0-150 # mount | grep devpts
devpts on /dev/pts type devpts (rw,nosuid,noexec,gid=5,mode=620,ptmxmode=000)
none on /jail/prod/j_192-168-0-150/mnt/dev/pts type devpts (rw,newinstance)
hardened-server j_192-168-0-150 # pwd
/jail/prod/j_192-168-0-150
hardened-server j_192-168-0-150 # gradm -n j_192-168-0-150
hardened-server j_192-168-0-150 # chroot mnt bash -l
hardened-server / # cd /dev
hardened-server dev # ls
ls: cannot access pts: No such file or directory
null  pts  shm  urandom  zero
hardened-server dev # ls -l
ls: cannot access pts: No such file or directory
total 4
crw------- 1 root root 1, 3 Sep 11  2008 null
d????????? ? ?    ?       ?            ? pts
drwxr-xr-x 2 root root 4096 Sep 11  2008 shm
crw-rw-rw- 1 root root 1, 9 Feb  7 21:29 urandom
crw-rw-rw- 1 root root 1, 5 Apr 12  2009 zero
hardened-server dev # logout
hardened-server j_192-168-0-150 # logout
hardened-server j_192-168-0-150 # gradm -a admin
Password:
hardened-server j_192-168-0-150 # umount mnt/dev/pts/
hardened-server j_192-168-0-150 # bash
hardened-server j_192-168-0-150 # gradm -n j_192-168-0-150; chroot mnt bash -l
hardened-server / # cd /dev
hardened-server dev # ls
null  pts  shm  urandom  zero
hardened-server dev # ls -l
total 8
crw------- 1 root root 1, 3 Sep 11  2008 null
drwxr-xr-x 2 root root 4096 Sep 11  2008 pts
drwxr-xr-x 2 root root 4096 Sep 11  2008 shm
crw-rw-rw- 1 root root 1, 9 Feb  7 21:29 urandom
crw-rw-rw- 1 root root 1, 5 Apr 12  2009 zero


Full role description:

Code: Select all

role j_192-168-0-150 sTN
subject /
    / h
    /bin/chroot x
    /bin/sleep x
    /jail/prod/j_192-168-0-150/mnt rwcdmlxi
    /jail/prod/j_192-168-0-150/mnt/boot h
    /jail/prod/j_192-168-0-150/mnt/cgroup h
    /jail/prod/j_192-168-0-150/mnt/dev r
    /jail/prod/j_192-168-0-150/mnt/dev/fd r
    /jail/prod/j_192-168-0-150/mnt/dev/log cdrw
    /jail/prod/j_192-168-0-150/mnt/dev/null rw
    /jail/prod/j_192-168-0-150/mnt/dev/pts h
    /jail/prod/j_192-168-0-150/mnt/dev/pty* rw
    /jail/prod/j_192-168-0-150/mnt/dev/shm rw
    /jail/prod/j_192-168-0-150/mnt/dev/std* r
    /jail/prod/j_192-168-0-150/mnt/dev/tty rw
    /jail/prod/j_192-168-0-150/mnt/dev/tty* rw
    /jail/prod/j_192-168-0-150/mnt/dev/urandom rw
    /jail/prod/j_192-168-0-150/mnt/dev/XOR r
    /jail/prod/j_192-168-0-150/mnt/dev/zero rw
    /jail/prod/j_192-168-0-150/mnt/proc r
    /jail/prod/j_192-168-0-150/mnt/proc/cpuinfo r
    /jail/prod/j_192-168-0-150/mnt/proc/loadavg r
    /jail/prod/j_192-168-0-150/mnt/proc/meminfo r
    /jail/prod/j_192-168-0-150/mnt/proc/self r
    /jail/prod/j_192-168-0-150/mnt/proc/stat r
    /jail/prod/j_192-168-0-150/mnt/proc/uptime r
    /jail/prod/j_192-168-0-150/mnt/proc/version r
    /jail/prod/j_192-168-0-150/mnt/proc/a* h
    /jail/prod/j_192-168-0-150/mnt/proc/b* h
    /jail/prod/j_192-168-0-150/mnt/proc/c* h
    /jail/prod/j_192-168-0-150/mnt/proc/d* h
    /jail/prod/j_192-168-0-150/mnt/proc/e* h
    /jail/prod/j_192-168-0-150/mnt/proc/f* h
    /jail/prod/j_192-168-0-150/mnt/proc/g* h
    /jail/prod/j_192-168-0-150/mnt/proc/h* h
    /jail/prod/j_192-168-0-150/mnt/proc/i* h
    /jail/prod/j_192-168-0-150/mnt/proc/j* h
    /jail/prod/j_192-168-0-150/mnt/proc/k* h
    /jail/prod/j_192-168-0-150/mnt/proc/l* h
    /jail/prod/j_192-168-0-150/mnt/proc/m* h
    /jail/prod/j_192-168-0-150/mnt/proc/n* h
    /jail/prod/j_192-168-0-150/mnt/proc/o* h
    /jail/prod/j_192-168-0-150/mnt/proc/p* h
    /jail/prod/j_192-168-0-150/mnt/proc/q* h
    /jail/prod/j_192-168-0-150/mnt/proc/r* h
    /jail/prod/j_192-168-0-150/mnt/proc/s* h
    /jail/prod/j_192-168-0-150/mnt/proc/t* h
    /jail/prod/j_192-168-0-150/mnt/proc/u* h
    /jail/prod/j_192-168-0-150/mnt/proc/v* h
    /jail/prod/j_192-168-0-150/mnt/proc/w* h
    /jail/prod/j_192-168-0-150/mnt/proc/x* h
    /jail/prod/j_192-168-0-150/mnt/proc/y* h
    /jail/prod/j_192-168-0-150/mnt/proc/z* h
    /jail/prod/j_192-168-0-150/mnt/proc/*/cmdline r
    /jail/prod/j_192-168-0-150/mnt/proc/*/coredump_filter rw
    /jail/prod/j_192-168-0-150/mnt/proc/*/cwd r
    /jail/prod/j_192-168-0-150/mnt/proc/*/environ r
    /jail/prod/j_192-168-0-150/mnt/proc/*/exe r
    /jail/prod/j_192-168-0-150/mnt/proc/*/fd r
    /jail/prod/j_192-168-0-150/mnt/proc/*/fdinfo r
    /jail/prod/j_192-168-0-150/mnt/proc/*/ipaddr r
    /jail/prod/j_192-168-0-150/mnt/proc/*/limits r
    /jail/prod/j_192-168-0-150/mnt/proc/*/loginuid r
    /jail/prod/j_192-168-0-150/mnt/proc/*/root r
    /jail/prod/j_192-168-0-150/mnt/proc/*/sessionid r
    /jail/prod/j_192-168-0-150/mnt/proc/*/stat r
    /jail/prod/j_192-168-0-150/mnt/proc/*/statm r
    /jail/prod/j_192-168-0-150/mnt/proc/*/status r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/cmdline r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/cwd r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/environ r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/exe r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/fd r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/fdinfo r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/limits r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/loginuid r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/root r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/sessionid r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/stat r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/statm r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/status r
    /jail/prod/j_192-168-0-150/mnt/proc/*/task/*/* h
    /jail/prod/j_192-168-0-150/mnt/proc/*/* h
    /jail/prod/j_192-168-0-150/mnt/sys h
    ip_override 192.168.0.150
    connect 127.0.1.0/24 stream tcp dgram udp
    connect ! 127.0.0.0/16 stream tcp dgram udp
    connect 0.0.0.0/0 stream tcp dgram udp
    bind 192.168.0.150 stream tcp dgram udp
    bind 127.0.1.0/24 stream tcp dgram udp


Yes, this is a known bug which can't be fixed easily. It's been reported on the forums several times before: basically it's not possible to hide mount paths with a single normal object. You could try using the globbed object "/dev/pts* h" however; that may work.

-Brad