grsecurity forums

Hello,
on our systems we sometime need to install system-wide application that is less trusted and should be used just by few users that really need it. As well we have some dedicated users (e.g. who run servers) and we would like to ensure they should execute only given one/two programs (+ several standard programs).
This is partially possible with grsecurity, but perhaps heaving a clear list of who can run what would be easier to configure, and more flexible if instead a constant list we would call a program that will permit/deny (and can take other factors into account like current time, resources, or even ask for special authorization and await confirmation by admin e.g. via email)

We want to propose a two major ways to control files execution:

1. Set for user
User can execute specified files only.

or

2. Set for file
File can be executed by specified user only. That will apply for example to any server applications with separate user created only for this application.

This restrictions have their purpose if there is set of finite trusted files needed by user to perform daily actions.

All this can be done with chmod command and groups but it fails in some cases (for example command 'aptitude upgrade' will rewrite the permissions to binary), so we want something more basic and more elastic.

That functionality can be provided by grsecurity configuration file, or by application that controls all files execution. Application cotrolling execution of files has advantages over configuration file:
- Control: logging all files executions
- Information and feedback to user

The closest option to this idea that we have found is Trusted Path Execution (GRKERNSEC_TPE):

"If you say Y here, you will be able to choose a gid to add to the
supplementary groups of users you want to mark as "untrusted."
These users will not be able to execute any files that are not in
root-owned directories writable only by root. If the sysctl option
is enabled, a sysctl option with name "tpe" is created."

So there is lack of a handy tool for setting permisions for execution per file/user. We think that this is a good idea to discuss. What do you think?

on our systems we sometime need to install system-wide application that is less trusted and should be used just by few users that really need it. As well we have some dedicated users (e.g. who run servers) and we would like to ensure they should execute only given one/two programs (+ several standard programs).
This is partially possible with grsecurity [...]

Which part is FULLY not possible with grsec MAC? As far as explained above, I see no problem with solving it completly with grsecurity policy; for example:

Code: Select all

role default
  subject /
     / rx
     /opt/less_trusted_apps h # "system-wide applications that are less trusted" are located here and hidden by default

# users in group "really_needit_users" who should be allowed to execute "system-wide applications that are less trusted" mentioned above

role really_needit_users g 
  subject /
    / rx # note there is no limiting access to  /opt/less_trusted_apps for this group

# users in group "dedicated_users" who run servers
role dedicated_users g
  subject /
    / # nothing allowed by default
    /usr/local/bin/program1 rx
    /usr/local/bin/program2 rx # users in this group should only execute one/two programs (program1 and program2)
    /bin rx # several standard programs which they are also allowed are in here


Is there something I'm missing so far?

but perhaps heaving a clear list of who can run what would be easier to configure, and more flexible if instead a constant list we would call a program that will permit/deny (and can take other factors into account like current time, resources, or even ask for special authorization and await confirmation by admin e.g. via email)

Such an advanced application can surely never be part of kernel patch such as grsecurity. If you really want that, you can do it with ordinary DAC and custom written app/daemon (for example, having special application accessible only by some group, having app or daemon running SETGID that group, and executing restricted apps only when your special requirements (current time, resources, authorization via e-mail, etc) are met. (You may also use grsec MAC for that purpose, but there is no need that I can see).

All this can be done with chmod command and groups but it fails in some cases (for example command 'aptitude upgrade' will rewrite the permissions to binary), so we want something more basic and more elastic

You may want to look into dpkg-statoverride(8) command so system upgrade won't break your DAC permissions (also take a look at dpkg-divert(8) if you want to stop upgrade from breaking your replacement application wrappers, for example)

Thank you for your answer. I was not aware that this could be done by RBAC.