How to tell what role a process has

[countermode]

Hello,

is there a way to tell what role a process currently has?

Moreover, just to make sure I got that right: If a process P enters a role, say role R, and P forks off process Q, then Q inherits role R until P terminates; upon termination of P Q falls back into its default role - correct?

Thanks
ctr

[spender]

Hi,

That kind of behavior only pertains to special roles. What special role a process is in can be seen with /proc/pid/status. User/group roles are only changed upon modification of the real uid/gid of a process. Thus the suid/sgid binaries executed from a given role still stay in that given role (if/until the real uid/gid is changed by that binary).

-Brad

[countermode]

Hi Brad,

I see.

Now: If I want to secure a set of daemons (say an MTA like postfix) such that neither the daemons can misbehave too badly nor can the (ordinary) root user do mischief. I thought about assigning a special role to the daemons and not using the default role. (Where's the point of having roles if you cram everything into the default role?) You once mentioned elsewhere that there is no automatic transition for processes by executable file name, and that one needs to use a special role without authentication and using a kind of wrapper. I would not like that, it would be dirty hack. Is it inherently impossible for grsec to assign a role other than the default role to a group of processes (not having the same uid/gid) by a policy rule? Or is it just something that you think is not right?

The only other way I could imagine is to run all daemons in the group under one common uid and assign privileges there... but many daemons check that they have uid 0 and complain if they don't. One could give them euid 0. Requires suid. bah, yet another dirty hack.

How would you address that?

Best
ctr

[spender]

Hi,

You should think of the roles as a collection of subjects. It's the subjects that provide a majority of the separation, such that acceptable levels of separation can be provided within a single role. Various subject flags exist to control things like whether a process can be killed by a non-admin, etc.

I have a policy for postfix, it involves subjects in both a "root" user role, and a "postfix" user role that apply to all binaries associated with postfix (it's a directory subject). The postfix user role needs very little runtime permissions:

Code: Select all

role postfix u
   subject /  {
      /                                                  h
      /etc/passwd                                        r
      /var/spool/postfix/flush
      -CAP_ALL
      bind      disabled
      connect   disabled
   }

   subject /usr/lib/postfix o {
      /                                                  h
        /dev/log rw
        /etc/localtime r
        /dev/null                                        rw
      /etc/passwd                                        r
      /var/spool/postfix                                 rwcd
      /var/spool/postfix/etc                             r
      /var/spool/postfix/lib                             rx
      /var/spool/mail                                    rwcd
      /var/mail                                  rwcd
      /usr/share                                         r
      /var/run/.nscd_socket                              rw
        /proc/meminfo r
        /proc/sys/kernel r
        /var/run
      -CAP_ALL
   }


The subject for the root role needs a handful of capabilities but not many additional filesystem permissions. The mail server needs read/write access to the mail spools for all users on the system and not much else.

Have you tried using the learning mode to generate a policy? It will likely do a better job than one developed by hand (and it's easily tweakable with the learn_config file).

-Brad

[countermode]

Hi Brad,

thanks for your reply and the demo policy for postfix. I see your point, but I still claim that the role concept is somewhat odd for daemons. For an admin that logs in as root finds himself in the same role (namely root) as, say the postfix master process. Possibly together with other (unrelated) daemon processes.

I believe that the concept that grsec pursues is sufficient, at the same time, distributing a set of closely interrelated processes over various roles is unnatural.

Btw. I do know about the learnig mode, I am playing with that already.


Best
ctr

[timbgo]

Hi,

You should think of the roles as a collection of subjects. It's the subjects that provide a majority of the separation, such that acceptable levels of separation can be provided within a single role. Various subject flags exist to control things like whether a process can be killed by a non-admin, etc.

I have a policy for postfix, it involves subjects in both a "root" user role, and a "postfix" user role that apply to all binaries associated with postfix (it's a directory subject). The postfix user role needs very little runtime permissions:

Code: Select all

role postfix u
   subject /  {
      /                                                  h
      /etc/passwd                                        r
      /var/spool/postfix/flush
      -CAP_ALL
      bind      disabled
      connect   disabled
   }

   subject /usr/lib/postfix o {
      /                                                  h
        /dev/log rw
        /etc/localtime r
        /dev/null                                        rw
      /etc/passwd                                        r
      /var/spool/postfix                                 rwcd
      /var/spool/postfix/etc                             r
      /var/spool/postfix/lib                             rx
      /var/spool/mail                                    rwcd
      /var/mail                                  rwcd
      /usr/share                                         r
      /var/run/.nscd_socket                              rw
        /proc/meminfo r
        /proc/sys/kernel r
        /var/run
      -CAP_ALL
   }


The subject for the root role needs a handful of capabilities but not many additional filesystem permissions. The mail server needs read/write access to the mail spools for all users on the system and not much else.

Have you tried using the learning mode to generate a policy? It will likely do a better job than one developed by hand (and it's easily tweakable with the learn_config file).

-Brad

Hi, spender and everyone!

I've finally deployed RBAC policy, I've been making really determined attempts for long time. Such a lot of different things to learn!

And it feels great, finally browsing the web (with incomplete but pretty safe browser dillo, and occasional help of lynx)...

I have posted earlier version of my /etc/grsec/policy here:

A no-poetteringware desktop RBAC policy
viewtopic.php?f=5&t=4153

I have a few questions/queries/difficulties left.

And the first is how risky is it for someone to post their policy online.

I did it in the link given, regardless of how risky it is, so other users may benefit.

Another one has just been solved:

gradm -a admin says "Invalid password."
viewtopic.php?f=5&t=4056#p14512

And another query is, I'd like to keep the option to have:

Code: Select all

/proc/sys/kernel/grsecurity/exec_logging

and

Code: Select all

/proc/sys/kernel/grsecurity/audit_chdir

on and off (1 and 0).
Keeping it on is too verbose (unless, subquery:

anyone knows a good way to control that verbosity?
any quick links on the issue?
),
and I'd need them for, say, this bash script of mine:

https://github.com/miroR/uncenz

where I use exec_logging to detect when the ffmpeg started screencasting.

(It's more of an idea for a program, I'm not very advanced.)

I understand that it would be best to issue:

Code: Select all

echo 1 > /proc/sys/kernel/grsecurity/grsec_lock

after one sets all up after boot and after enabling the RBAC...

How much of a risk is it if grsec_lock is left unlocked, at value 0?

And another query is, I just don't get how it can be possible to get postfix
to work as you described in your post.

In my worked and reworked (for all this time since I posted it) policy, I
couldn't get any less then all those subjects, and added a few more, as in the
posted policy (link given above)...

If it's not such great risk, I can post my current policy, if it could be
helpful to other users (which I am not sure of, too lengthy, 100k!).

Really happy that I'm finally using grsecurity/PaX about fully and properly
deployed! It is however much more work than the mere installing and
configuration is, which I managed somehow to get a lot of people interested in
with my Tips on the Debian Forums:

Grsecurity/Pax installation on Debian GNU/Linux
http://forums.debian.net/viewtopic.php?f=16&t=108616

I wish to make a second Tip about RBAC learning and configuring for beginners,
but that really is so much more work, who knows if I make it some time in the
future...

And another question (or should I put it to PaX Team): can I use the

http://pax.grsecurity.net/tux_pen1.jpg
from
http://pax.grsecurity.net

rework it a little (keeping it under some compatible license, I like CreativeCommons-4.0)

and use it, such as make it my logo on Gentoo Forums? Please!

Cheers!

Miroslav Rovis
http://www.CroatiaFidelis.hr