grsecurity forums

Hello,

is it possible, without knowing about usernames and possible actions, to write an RBAC policy file that allows every user to perform exactly the same actions as on the same machine without RBAC?

I thought that the following short policy file would do the job:

role admin sA
subject / rvka
/ rwacdmlxi

role default G
role_transitions admin
subject /
/ rwacdmlxi

And it seems it does. But when I want to disable RBAC and type in my password, I get the error message "Invalid password." I am sure that I did not mistype my password for so many times.

Does my policy file do what I want? And why can I not disable RBAC after I have enabled it with that policy?

Regards
Christoph

Hello,

I forgot to mention that I changed the source code of gradm so that the program does not exit if security holes are found in the policy.

Regards
Christoph

You need to add "ra" to the "subject /" line, to weaken ptrace restrictions and allow that subject to authenticate to the kernel with gradm.

-Brad

Hello,

spender wrote:You need to add "ra" to the "subject /" line, to weaken
ptrace restrictions and allow that subject to authenticate to the kernel
with gradm

I applied the suggested change and the problem was solved.

Now I have a problem with the kaffeine multimedia player. It does not play
some video files when the "Restrict mprotect" feature of PAX is enabled. As
a first attempt, I added a line to my configuration:

Code: Select all

role admin sA
subject / rvka
        / rwacdmlxi

role default G
role_transitions admin
subject / ra
        / rwacdmlxi
        -PAX_MPROTECT


With that configuration, kaffeine was able to play all files again.

But of course I only want to turn off PAX_MPROTECT in kaffeine, not in all
executables. So, I rewrote my configuration:

Code: Select all

role admin sA
subject / rvka
        / rwacdmlxi

role default G
role_transitions admin
subject / ra
        / rwacdmlxi

subject /usr/bin/kaffeine
        / rwacdmlxi
        -PAX_MPROTECT


That configuration did not solve my kaffeine problem. I was not even able to
strace kaffeine.

What is wrong with the second configuration?

Regards
Christoph

Can you show the logs or through some other way how it was failing?

-Brad

spender wrote:Can you show the logs or through some other way how it was failing?

Without trying to strace kaffeine, nothing appears in the logs.

With stracing, the following message appears in the logs:

Code: Select all

May  7 08:45:24 alpha kernel: grsec: (default:D:/) denied ptrace of /usr/bin/kaffeine by /usr/bin/kaffeine[strace:8389] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/strace[strace:8388] uid/euid:1000/1000 gid/egid:1000/1000


The strace output is:

Code: Select all

8389  execve("/usr/bin/kaffeine", ["kaffeine"], [/* 35 vars */]) = -1 EACCES (Pe
rmission denied)
8389  dup(2)                            = 3
8389  fcntl64(3, F_GETFL)               = 0x2 (flags O_RDWR)
8389  fstat64(3, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
8389  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x9a2e1000
8389  _llseek(3, 0, 0xb1d98184, SEEK_CUR) = -1 ESPIPE (Illegal seek)
8389  write(3, "strace: exec: Permission denied\n", 32) = 32
8389  close(3)                          = 0
8389  munmap(0x9a2e1000, 4096)          = 0
8389  exit_group(1)                     = ?


If you chpax -m /usr/bin/kaffeine does it work properly? does adding "o" or "or" to the subject mode for /usr/bin/kaffeine change anything?

-Brad

spender wrote:If you chpax -m /usr/bin/kaffeine does it work properly? does adding "o" or "or" to the subject mode for /usr/bin/kaffeine change anything?

chpax helps, changing the subject mode neither makes kaffeine work nor lets me strace it.

Regards
Christoph

What version of grsecurity are you using? It's working fine for me here. Can you find the PID of the kaffeine process when it's running and verify that the "m" in the PaX field of /proc/<pid>/status is lowercase instead of uppercase when only -PAX_MPROTECT on that subject is being used? Everything looks fine on my end, so I can't tell yet what's causing the problems you've having.

-Brad

spender wrote:What version of grsecurity are you using?

Kernel 2.6.24.5 with the latest stable version of grsecurity.

spender wrote:Can you find the PID of the kaffeine process when it's running and verify that the "m" in the PaX field of /proc/<pid>/status is lowercase instead of uppercase when only -PAX_MPROTECT on that subject is being used?

It is an uppercase "M".

Regards
Christoph

Ah jeez, sorry just noticed this. You have "i" in subject /, which means that anything executed by that default subject will inherit subject /, including kaffeine. Remove the "i" from the default subject and the problem will go away.

-Brad

spender wrote:Remove the "i" from the default subject and the problem will go away.

When I remove "i" from the default subject, what will happen to other programs than kaffeine? Because for them, inheriting the default mode is what I want.

Regards
Christoph

They get the default subject, since you have no other subjects that could possibly apply. Just as you have a /usr/bin/kaffeine subject, if you also had a /usr/bin/top subject, executing /usr/bin/top would cause it to get the /usr/bin/top subject. So removing the "i" from the default subject gives you exactly the policy you intended.

-Brad

spender wrote:So removing the "i" from the default subject gives you exactly the policy you intended.

Now I am able to use kaffeine as expected, but I am not able to strace it. What do I need to add for stracing?

Regards
Christoph

You may need to add "A" to the default role.

-Brad