headers
Hrvoje Marjanovic | 4 Jan 2007 19:40
Picon

logging command arguments

Hello,

I am wondering if it is possible to log complete commands (together with 
arguments) with RSBAC.

When I log EXECUTE events on FILE target. I get the events logged, but 
arguments are not logged, only command path, user, pid etc.

Grsecurity has such a feature, but I don't think it is possible to patch 
kernel with both grsecurity and rsbac.

Hrvoje
Permalink | Reply | 2 comments |
headers
Amon Ott | 9 Jan 2007 09:46

Re: logging command arguments

On Donnerstag 04 Januar 2007 19:40, Hrvoje Marjanovic wrote:
> I am wondering if it is possible to log complete commands (together 
with 
> arguments) with RSBAC.
> 
> When I log EXECUTE events on FILE target. I get the events logged, 
but 
> arguments are not logged, only command path, user, pid etc.
> 
> Grsecurity has such a feature, but I don't think it is possible to 
patch 
> kernel with both grsecurity and rsbac.

We discussed this idea some time ago, but decided not to log the 
arguments. They blow up the logs significantly, produce extra 
overhead and are seldom needed. If you convince us that it is a 
necessary feature, we can add it as an option.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
Permalink | Reply | 0 comments |
headers
kang | 11 Jan 2007 17:57

RSBAC 1.3.1 Released

RSBAC 1.3.1 has been released for both kernels 2.4.34 and 2.6.19.2.

You can download the new version from http://www.rsbac.org/download
(Quick download from http://www.rsbac.org/download/quick).

Improvements over version 1.3.0:

- Add xstats counter for get_parent calls.
- Fix sort order of network templates.
- Add missing DAZ request in vector. Add role number in RC syscall
denied log message.
- Create bitmasks for each module of which requests it is interested in
and only call request_xy and set_attr_xy, if necessary.
- Small performance tunning: removed usage of rsbac_list_compare_u32
(always use memcmp which is asm-tuned per arch)
- Reduce stack usage in list, ACL and RC init.
- Optimize list hash functions with bit masks instead of % operation.
- Fixed LVM/MD issues with rsbac automounting.
- Rewritten the way rsbac_jail is entering new namespace. Now works
correctly :)

Thanks !
Permalink | Reply | 0 comments |
headers
kang | 16 Jan 2007 11:41

Re: logging command arguments

Hrvoje Marjanovic wrote:
> Hello,
>
> I am wondering if it is possible to log complete commands (together with 
> arguments) with RSBAC.
>
> When I log EXECUTE events on FILE target. I get the events logged, but 
> arguments are not logged, only command path, user, pid etc.
>
> Grsecurity has such a feature, but I don't think it is possible to patch 
> kernel with both grsecurity and rsbac.
>
> Hrvoje
>   

It requires some hand patching but several people have successfully
patched kernels with both RSBAC and GrSecurity (1).
Note that a lot of functionality from GrSec's RBAC will overlap however.
Additionally, I am not aware of any of the patches being available online.

kang

1) http://www.rsbac.org/pipermail/rsbac/2005-August/001615.html
Permalink | Reply | 0 comments |
headers
Jens Kasten | 21 Jan 2007 21:33
Picon

auth set

hi liste,
i have the follow  logging
/* Sun Sep 17 06:05:12 2006 :<6>0202899220|rsbac_adf_request(): request 
CHANGE_DAC_FS_OWNER, pid 16017, ppid 1, 
prog_name master, prog_file /usr/lib/postfix/master,
 uid 0, remote ip 192.168.1.5, target_type PROCESS, 
 tid 16017, attr owner, value 103, result NOT_GRANTED (Softmode) by AUTH  */

but when i set like this,
auth_set_cap -f  PROCESS add /usr/lib/postfix/master 103
i get this,
Error: RSBAC_EINVALIDTARGET

the rsbac_menu dont log in the menu-log the action what i do with auth, for 
this i dont have a working example.
can someone explain me the auth_set_cap?

mfg 
igraltist
Permalink | Reply | 2 comments |
headers
Amon Ott | 22 Jan 2007 09:08

Re: auth set

On Sonntag 21 Januar 2007 21:33, Jens Kasten wrote:
> i have the follow  logging
> /* Sun Sep 17 06:05:12 2006 :<6>0202899220|rsbac_adf_request(): 
request 
> CHANGE_DAC_FS_OWNER, pid 16017, ppid 1, 
> prog_name master, prog_file /usr/lib/postfix/master,
>  uid 0, remote ip 192.168.1.5, target_type PROCESS, 
>  tid 16017, attr owner, value 103, result NOT_GRANTED (Softmode) by 
AUTH  */
> 
> but when i set like this,
> auth_set_cap -f  PROCESS add /usr/lib/postfix/master 103
> i get this,
> Error: RSBAC_EINVALIDTARGET

You set the cap at the program file, not the process:

auth_set_cap FILE /usr/lib/postfix/master 103

After restarting postfix, master runs with the correct set. BTW, many 
postfix helper programs need this cap, so in RSBAC 1.3 you could also

auth_set_cap DIR /usr/lib/postfix 103

to get the cap set inherited to all programs in that dir.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
(Continue reading)

Permalink | Reply | 0 comments |
headers
Colin Pitrat | 22 Jan 2007 09:10
Picon

Re: auth set

With type PROCESS, you should send a pid. If you want to set this right 
on /usr/lib/postfix/master, use FILE :
auth_set_cap -f FILE add /usr/lib/postfix/master 103

If you use PROCESS, it will only affect current process. After a reboot, 
or if you restart postfix, the right will be lost.

Regards,
Colin Pitrat (Bull Services Telco)
Bull,  Architect of an Open World (TM)
Tél : +33 (0)  1 30 80 72 93
www.bull.com

Jens Kasten wrote:
> hi liste,
> i have the follow  logging
> /* Sun Sep 17 06:05:12 2006 :<6>0202899220|rsbac_adf_request(): request 
> CHANGE_DAC_FS_OWNER, pid 16017, ppid 1, 
> prog_name master, prog_file /usr/lib/postfix/master,
>  uid 0, remote ip 192.168.1.5, target_type PROCESS, 
>  tid 16017, attr owner, value 103, result NOT_GRANTED (Softmode) by AUTH  */
> 
> but when i set like this,
> auth_set_cap -f  PROCESS add /usr/lib/postfix/master 103
> i get this,
> Error: RSBAC_EINVALIDTARGET
> 
> the rsbac_menu dont log in the menu-log the action what i do with auth, for 
> this i dont have a working example.
> can someone explain me the auth_set_cap?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jens Kasten | 23 Jan 2007 02:32
Picon

auth_set_cap

hi,
thanks for explaining.
now i have found what i was searching.
from my logging example 

/* request  CHANGE_DAC_FS_OWNER, pid 16017, ppid 1, 
 prog_name master, prog_file /usr/lib/postfix/master,
  uid 0, remote ip 192.168.1.5, target_type PROCESS, 
  tid 16017, attr owner, value 103, result NOT_GRANTED (Softmode) by AUTH  */

i was always going with rsbac_fd_menu to /usr/lib/postfix/master and add there 
by AUTH FS Cababilities the value 103.

now iam doing map this request

const char *suche_change[] = {
		"CHANGE_OWNER", "CHANGE_DAC_FS_OWNER" , "CHANGE_DAC_EFF_OWNER", 
		"CHANGE_GROUP", "CHANGE_DAC_FS_GROUP" , "CHANGE_DAC_EFF_GROUP"		     
 		};
	
const char *setze_change[] = {
		"",    "-f" , "-e",
		"-g",  "-F",  "-E"
  	    };	

and can instert this as the request and have  this for set up.

auth_set_cap {request} FILE add {prog_file} {value}

and its work like how iam doing it from the rsbac_menu. :)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Amon Ott | 23 Jan 2007 09:38

Re: auth_set_cap

On Dienstag 23 Januar 2007 02:32, Jens Kasten wrote:
> /* request  CHANGE_DAC_FS_OWNER, pid 16017, ppid 1, 
>  prog_name master, prog_file /usr/lib/postfix/master,
>   uid 0, remote ip 192.168.1.5, target_type PROCESS, 
>   tid 16017, attr owner, value 103, result NOT_GRANTED (Softmode) by 
AUTH  */

> one question i have, must i really restart the services after setup 
this?
> i ask because when i set up it, then it disappears from the log.
> this looks a bit more complicatet, because the security-user has no 
rights for 
> restarting the services and from the log-file i get not the real 
programname 
> which must restart. 

In addition to setting the cap at the program, just
auth_set_cap PROCESS add 16017 103

This is what AUTH learning mode does: Set the cap for both program 
file and process.

Amon.
--

-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
_______________________________________________
rsbac mailing list
rsbac <at> rsbac.org
http://www.rsbac.org/mailman/listinfo/rsbac
Permalink | Reply | 0 comments |
headers
Orosz Tamás | 30 Jan 2007 14:45
Picon

Unhandled error RSBAC_EEXPIRED

Dear List,

I tried use RSBAC UM, and I got the following error when trying change user id eg. with su (id change is successfull):

# su www-data
pam_rsbac.so: Unhandled error RSBAC_EEXPIRED, please contact system administrator!
su: Authentication service cannot retrieve authentication info.
(Ignored)
sh-2.05b$

user information of www-data (maybe this account is not expired):

Uid: 33
Name: www-data
Fullname: www-data
Shell: /bin/sh
Homedir: /var/www
Group: 33
Lastchange: 19700101
Minchange: 0
Maxchange: 365
Warnchange: 10
Inactive: 3
Expire: 20241004
Account TTL: 0

I think this error prevent running crontabs an another user as root (non-root crontabs are not running
since I use RSBAC UM).

Rsbac version: 1.2.8 with kernel 2.6.17.8
(Continue reading)

Permalink | Reply | 1 comment |

Gmane