grsecurity forums

Hi,

I'm using Gentoo Hardened, with musl on an armv7 device. Gradm reports that the gradm version and kernel are incompatible.

Installed packages:

Code: Select all

root@lostmemory ~ # eix -cIe gradm
[I] sys-apps/gradm (3.0.201408301734@01/18/15): Administrative interface for the grsecurity Role Based Access Control system
root@lostmemory ~ # eix -cIe hardened-sources
[I] sys-kernel/hardened-sources (3.18.5-r1(3.18.5-r1)@02/15/15): Hardened kernel sources (kernel series 3.18)


gradm -S reporting an error:

Code: Select all

root@lostmemory ~ # gradm -S
The /dev/grsec device is not properly installed on your system or you are not using a grsecurity kernel.


/dev/grsec exists:

Code: Select all

# ls -l /dev/grsec                                                                                             
crw--w--w- 1 root root 1, 13 Feb 15 01:48 /dev/grsec


Running a different command (I am not sure if this command is sensible - but still, the error should be telling):

Code: Select all

# gradm -D
Password:
You are using incompatible versions of gradm and grsecurity.
Please update both versions to the ones available on the website.
Make sure your gradm has been compiled for the kernel you are currently running.


Linux version:

Code: Select all

# uname -a
Linux lostmemory 3.18.5-hardened-r1lostmemory #1 SMP Sun Feb 15 01:46:07 CET 2015 armv7l Allwinner A1X (Device Tree) GNU/Linux


Musl libc version:

Code: Select all

# /usr/lib/libc.so
musl libc
Version 1.1.6
Dynamic Program Loader
Usage: /usr/lib/libc.so [options] [--] pathname [args]


Gradm version:

Code: Select all

# gradm --version
gradm v3.0 - grsecurity RBAC administration and policy analysis utility


I am a bit lost. I have not tested this with glibc, because I don't have a hardened armv7 system with glibc; but I presume that it will work.
Any clue why this would go wrong? I checked the kernel source some time ago, as well as the gradm source, and saw that (obviously) both define (the same) structs that are used to define the messages being communicated. Perhaps some of the types do not match?

Help and pointers would be appreciated.

Does anything appear in dmesg?

Can you compile and provide me the output of this:

Code: Select all

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>

int main(void)
{
        printf("%u %u\n", sizeof(ino_t), sizeof(uid_t));
        return 0;
}


-Brad

Hi,

Nothing seems to show up in dmesg.

Here's the output of the program you pasted:

Code: Select all

~/test/grsec $ cat > main.c
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>

int main(void)
{
        printf("%u %u\n", sizeof(ino_t), sizeof(uid_t));
        return 0;
}
~/test/grsec $ gcc main.c -o main
~/test/grsec $ ./main
8 4


Cheers,
Merlijn

Hi,

A remark. I compiled the same program on another armv7 machine, which has glibc (but no hardened-sources, as mainline support isn't too well yet), and there the result is different:

Code: Select all

/tmp $ cat > main.c
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
int main(void)
{
        printf("%u %u\n", sizeof(ino_t), sizeof(uid_t));
        return 0;
}
/tmp $ gcc main.c -o main
/tmp $ ./main
4 4


Cheers,
Merlijn

For now can you just run this in the gradm source directory:

sed -i 's/ino_t/unsigned long/' ./*

then recompile gradm, and see if that fixes the issues.

-Brad

Hi!

That seems to have fixed the problem. I will experiment and see if I run into other issues.

Code: Select all

gradm # ./gradm -S
The RBAC system is currently disabled.


Cheers,
Merlijn

So I asked the musl people about this, and they said that inode numbers are 64 bit.

With glibc, you should apparently use -D_FILE_OFFSET_BITS=64 to prevent (random) trouble: using the old ino_t mode can result in random EOVERFLOW when calling stat (and possibly other syscalls), if a file's inode number happens not to be <= 0xffffffff.

Furthermore, they said that future glibc versions might make that (-D_FILE_OFFSET_BITS=64) the default behaviour. So I guess that this (at some point) warrants an ABI bump?

Anyhow, thanks for the quick reaction. I'm looking forward to seeing a solution to this make its way into the package at some point.

This will be fixed in the next version of grsec.

I'll be porting the following code to the various kernels we support:
https://grsecurity.net/~spender/64bitino.diff

to be added to the current git gradm code:
https://cvsweb.grsecurity.net/?p=gradm. ... 225a277333

-Brad

Cool. I was wondering though, do you need to change 'ino_t' to 'u64'? As in, with the define it should work without replacing 'ino_t' with 'u64' or 'u_int64_t', right? (I thought that was the point of the define. Although that somehow contrasts the fact that musl was doing it 'right', and the kernel didn't accept it...)

And I was also thinking that in the kernel it is already defined as a 64 bit integer?

I didn't verify this, and I guess it doesn't matter too much. Thanks.

Cheers,
Merlijn

It's not defined as u64 in the kernel, it's unsigned long (which is what I was mimicking with gradm). Filesystems that support 64-bit inodes have their own containing struct, see the implementation of BTRFS_I:

Code: Select all

static inline struct btrfs_inode *BTRFS_I(struct inode *inode)
{
        return container_of(inode, struct btrfs_inode, vfs_inode);
}


So to get at those 64-bit inode numbers, you must obtain them from the containing struct, as the VFS layer does not inherently support them. So musl wasn't entirely relevant here to my choice of ino_t (and I was already using stat64(), etc).

-Brad

Right, thanks for the explanation. Furthermore, the latest gradm and hardened-sources seem to work on my musl armv7 system. Thank you for the quick reaction(s) and fix(es).