Page 1 of 1

Teaching shutdown role in full system learning mode

PostPosted: Mon May 30, 2011 12:43 pm
by jattila40
Please tell me, how can i teach the newly introduced special shutdown role in full learning mode? The shutdown role in the sample policy file doesn't work really. And just another question: how can i reach that the grsec not to write any message to console?

Thanx: Attila

Re: Teaching shutdown role in full system learning mode

PostPosted: Mon May 30, 2011 9:20 pm
by spender
What errors do you get when using the one provided in the default policy? I can fix it for all users. There's no support yet for generating learned policies for the shutdown role.

-Brad

Re: Teaching shutdown role in full system learning mode

PostPosted: Fri Jun 03, 2011 4:52 pm
by jattila40
I am using grsecurity patch for the 2.6.32.41 stable kernel. May be, this patch doesn't support shutdown special role?
Otherwise, how can i shutdown my system gracefully without using shutdown role? Is that a good idea to put the folowing script into the rc0.d, rc1.d, rc6.d directories:

#!/bin/bash
gradm -D << EOF
password_to_disable_RBAC
EOF

And when should this script run exactly (what should the nn number be in @Knn... link name. I am using Debian 6 amd64)

Thanx for your answer in advance: Jenei Attila

shutdown special role

PostPosted: Sun Jun 05, 2011 4:54 am
by jattila40
Ok, this patch does support shutdown role. Here is my shutdown log entries:
Code: Select all
Jun  4 00:00:06 netiphone1 kernel: [  500.079071] grsec: (root:U:/sbin/gradm) successful change to special role shutdown (id 1) by /sbin/gradm[gradm:3112] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3072] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:23 netiphone1 kernel: [  516.829966] grsec: (shutdown:S:/sbin/shutdown) persistent special role transferred privilege to init by /sbin/shutdown[shutdown:3113] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3072] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:23 netiphone1 kernel: [  516.848848] grsec: (shutdown:S:/) denied open of /root/.bash_history for appending by /bin/bash[bash:3072] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:23 netiphone1 kernel: [  516.848895] grsec: (shutdown:S:/) denied open of /root/.bash_history for reading by /bin/bash[bash:3072] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:23 netiphone1 kernel: [  517.587415] grsec: (root:U:/) use of CAP_KILL denied for /usr/sbin/apache2[apache2:3005] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:23 netiphone1 kernel: [  517.587421] grsec: (root:U:/) use of CAP_KILL denied for /usr/sbin/apache2[apache2:3005] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:23 netiphone1 kernel: [  517.587424] grsec: more alerts, logging disabled for 10 seconds
Jun  4 00:00:34 netiphone1 kernel: [  527.937548] grsec: (root:U:/) denied unlink of /var/run/apache2.pid by /usr/sbin/apache2[apache2:3005] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:35 netiphone1 kernel: [  529.249643] grsec: (default:D:/) denied access to hidden file /var/run by /usr/sbin/atd[atd:2967] uid/euid:1/0 gid/egid:1/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:35 netiphone1 kernel: [  529.533329] grsec: (root:U:/) denied unlink of /var/run/dirmngr/socket by /usr/bin/dirmngr[dirmngr:2505] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:36 netiphone1 kernel: [  530.385171] grsec: (default:D:/) denied access to hidden file /etc/localtime by /sbin/rpc.statd[rpc.statd:2196] uid/euid:102/102 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:36 netiphone1 kernel: [  530.385222] grsec: (default:D:/) denied access to hidden file /etc/localtime by /sbin/rpc.statd[rpc.statd:2196] uid/euid:102/102 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:36 netiphone1 kernel: [  530.385339] grsec: more alerts, logging disabled for 10 seconds
Jun  4 00:00:50 netiphone1 kernel: [  544.402709] grsec: (oracle:U:/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle) denied access to hidden file /usr/lib/oracle/xe/app/oracle/admin/XE/bdump by /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle[oracle:2835] uid/euid:1006/1006 gid/egid:1003/1003, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:50 netiphone1 kernel: [  544.403009] grsec: (oracle:U:/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle) denied access to hidden file /usr/lib/oracle/xe/app/oracle/admin/XE/bdump by /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle[oracle:2835] uid/euid:1006/1006 gid/egid:1003/1003, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:50 netiphone1 kernel: [  544.403554] grsec: (oracle:U:/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle) denied access to hidden file /usr/lib/oracle/xe/app/oracle/admin/XE/bdump by /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle[oracle:2835] uid/euid:1006/1006 gid/egid:1003/1003, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:50 netiphone1 kernel: [  544.403992] grsec: (oracle:U:/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle) denied access to hidden file /usr/lib/oracle/xe/app/oracle/admin/XE/bdump by /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle[oracle:2835] uid/euid:1006/1006 gid/egid:1003/1003, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:50 netiphone1 kernel: [  544.404100] grsec: (oracle:U:/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle) denied access to hidden file /usr/lib/oracle/xe/app/oracle/admin/XE/bdump by /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/oracle[oracle:2835] uid/euid:1006/1006 gid/egid:1003/1003, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Jun  4 00:00:50 netiphone1 kernel: [  544.562532] grsec: more alerts, logging disabled for 10 seconds
Jun  4 00:02:56 netiphone1 kernel: [  670.382548] grsec: (root:U:/usr/lib/vmware-tools/bin64/appLoader) denied open of /dev/null for reading by /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:3258] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:2038] uid/euid:0/0 gid/egid:0/0
Jun  4 00:02:56 netiphone1 kernel: [  670.382738] grsec: (root:U:/usr/lib/vmware-tools/bin64/appLoader) denied open of /dev/null for writing by /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:3258] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:2038] uid/euid:0/0 gid/egid:0/0
Jun  4 00:02:56 netiphone1 kernel: [  670.382799] grsec: (root:U:/usr/lib/vmware-tools/bin64/appLoader) denied open of /dev/null for writing by /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:3258] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:2038] uid/euid:0/0 gid/egid:0/0
Jun  4 00:02:56 netiphone1 kernel: [  670.387866] grsec: (root:U:/usr/lib/vmware-tools/bin64/appLoader) denied execution of /etc/vmware-tools/poweroff-vm-default by /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:3258] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:2038] uid/euid:0/0 gid/egid:0/0
Jun  4 00:03:04 netiphone1 kernel: [  678.414570] grsec: (root:U:/usr/lib/vmware-tools/bin64/appLoader) denied open of /dev/null for reading by /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:3260] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:2038] uid/euid:0/0 gid/egid:0/0
Jun  4 00:03:04 netiphone1 kernel: [  678.414791] grsec: more alerts, logging disabled for 10 seconds
Jun  4 00:03:15 netiphone1 kernel: [  689.503734] grsec: (root:U:/usr/lib/vmware-tools/bin64/appLoader) denied open of /dev/null for reading by /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:3265] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:2038] uid/euid:0/0 gid/egid:0/0
Jun  4 00:03:15 netiphone1 kernel: [  689.503965] grsec: (root:U:/usr/lib/vmware-tools/bin64/appLoader) denied open of /dev/null for writing by /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:3265] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:2038] uid/euid:0/0 gid/egid:0/0
Jun  4 00:03:15 netiphone1 kernel: [  689.504027] grsec: (root:U:/usr/lib/vmware-tools/bin64/appLoader) denied open of /dev/null for writing by /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:3265] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:2038] uid/euid:0/0 gid/egid:0/0
Jun  4 00:03:15 netiphone1 kernel: [  689.504154] grsec: (root:U:/usr/lib/vmware-tools/bin64/appLoader) denied execution of /etc/vmware-tools/poweroff-vm-default by /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:3265] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/vmware-tools/bin64/appLoader[vmtoolsd:2038] uid/euid:0/0 gid/egid:0/0


Why the shutdown role changes to root, default, oracle roles, when the parent subject is /sbin/init. Doesn't the persistence mean, that child subject inherits parent's role end keep it when parent exits? Am i something misunderstanding? And the working of f object flag isn't clear for me. Can you help me?

Thanks: Attila

Re: Teaching shutdown role in full system learning mode

PostPosted: Sun Jun 05, 2011 2:50 pm
by spender
What seems to be happening here is certain services are being "gracefully" shut down by sending a signal to the service. As far as the RBAC system is concerned, this activity is no different from activity the services perform at any other time. These aren't tasks that have been re-run by init, they only have init as their parent because they're run as daemons, which reparents the tasks to init. You'll just have to add these permissions to the respective subjects described in the error logs. In the future I'll add the shutdown role to full learning so that you can learn this as well.

-Brad

Re: Teaching shutdown role in full system learning mode

PostPosted: Sun Jun 05, 2011 3:23 pm
by jattila40
Thank you very much Brad! After sending my previous post, i thought this might be my problem. So i don't need to disable RBAC anyway during shutdown process, do i? But what is the best method to enable RBAC? Is this goot to put "gradm -E" into /etc/rc.local file (Debian)? Isn't this too late to protect my system properly? But if i enabled RBAC too early, it would result a too loose policy for normal use.
Attila

Re: Teaching shutdown role in full system learning mode

PostPosted: Sun Jun 05, 2011 4:14 pm
by spender
Make up two firewall scripts, one that denies everything and one that sets your normal firewall settings. Start the one when networking starts up, then the other after RBAC has been enabled. Putting gradm -E into rc.local lets you have stricter policies for services (as a lot of their needed permissions are only needed at startup). You can also use the 'gradm' match for iptables that is included with the patch. This blocks packets to the system when RBAC is disabled.

-Brad

Re: Teaching shutdown role in full system learning mode

PostPosted: Sun Jun 05, 2011 4:51 pm
by jattila40
Thank you for exhaustive answers, i have learnt a lot. After these, writing a good policy is up to me. Keep up the good work!

Attila

Re: Teaching shutdown role in full system learning mode

PostPosted: Tue Jun 07, 2011 8:11 pm
by spender
As a followup, I've uploaded a new version of gradm that adds some new features to produce policies through full learning that can be used more quickly without producing errors. There's a new "read-protected-path" directive in learn_config that I've matched up with the paths I enforce in the policy checking. I've also added globbing support to the read-protected-path, protected-path, and high-protected-path rules. Finally, I added support to allow the shutdown role to be used in full learning (and to produce it in the full learning output).

-Brad

Re: Teaching shutdown role in full system learning mode

PostPosted: Wed Jun 08, 2011 5:23 am
by jattila40
It's nice!
Just another problem:
I tried to stop RBAC during shutdown, and put an interactive shellscript into init.d directory to stop RBAC (interactive means: "# X-Interactive : true" line in the LSB header of the script, and the script name in the <interactive> section of /etc/insserv.conf file. Its purpose is, to enable gradm -D to prompt for a password). I want to stop RBAC immediately after all users logging off, but before daemons shutting down (as in the reverse order of enabling RBAC). It almost works correctly, but before prompting for the password, i get the folowing error message:

Jun 7 14:48:42 jeneidebian kernel: [ 105.620391] grsec: (root:U:/sbin/gradm) use of CAP_SYS_TTY_CONFIG denied for /sbin/gradm[gradm:1911] uid/euid:0/0 gid/egid:0/0, parent /etc/init.d/shutdownrbac[shutdownrbac:1909] uid/euid:0/0 gid/egid:0/0

four times. I tried to give gradm the CAP_SYS_TTY_CONFIG capability something like this:

subject /etc/init.d/shutdownrbac
/sbin/gradm rxi
-CAP_ALL
+CAP_SYS_TTY_CONFIG
+CAP_IPC_LOCK

This is not good, because /sbin/gradm looses all its objects given in built-in /sbin/gradm subject (it is invisibly added to policy by specifying G flag for the involving role). One solution would be to repeat all objects from invisible gradm subject, but this is not a good idea, because i don't want to let shutdownrbac script to access all the objects what gradm accesses to. Another solution would be not to replace the objects of gradm subject with objects of shutdownrbac subject (i flag is given to gradm object), but adding to them. So my question is: how can i add objects to invisible gradm subject? Or if i could see the gradm subject, i would simply add my objects to it, end the G role flag should be removed (has the G flag any other special functionality, then adding invisible gradm subject to the role?). Can you present the exact invisible gradm subject to me?

Thanks: Attila

Re: Teaching shutdown role in full system learning mode

PostPosted: Wed Jun 08, 2011 7:46 am
by spender
In gradm_adm.c:add_gradm_acl(), add the following at the bottom of the function:
add_cap_acl(current_subject, "+CAP_SYS_TTY_CONFIG", NULL);

I'll have to think of some easier solution to allow you to make these kinds of changes, as I don't want to allow this capability for all users.

-Brad