persist role when swithing users

Submit your RBAC policies or suggest policy improvements

persist role when swithing users

Postby cormander » Fri Oct 31, 2008 3:29 pm

Hello,

I'm wondering if it's possible to have a user role 'u' persist when you su to any other user, meaning you don't change roles when you switch users. What I'm seeing is if you su to another user you either inherit that user's user or group role, or the default role if none matches.

Basically looking for a way for identity to stick with you from the moment you login, w/o having to authenticate with gradm, and be unable to change it unless the role you want to switch to is in your role_transitions
cormander
 
Posts: 154
Joined: Tue Jan 29, 2008 12:51 pm

Re: persist role when swithing users

Postby spender » Fri Nov 07, 2008 8:27 pm

Automatic application of a persistent role should be possible with a custom PAM module to apply a non-authenticated special role upon login of a particular user.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Re: persist role when swithing users

Postby cormander » Sat Nov 08, 2008 4:09 am

OK I'm almost there, I think...

Here is my test role:

Code: Select all
role root sAN
subject / rvka
        / rwcdmlxi


As root, I can do "gradm -n root" and I get to the role successfully.

Here is the chunk of code I have for my pam function (I'm linking against all the gradm *.o files so there are no unresolved symbols)

Code: Select all
    special_role_uid = 0;
    tailor_to_kernel();
    main_stack = &include_stack;
    memset(main_stack, 0, sizeof(struct include_entry));
    main_stack->sp = -1;

    pam_syslog(pamh, LOG_WARNING, "initting variables");
    init_variables();

    err = mlock(&entry, sizeof (entry));
    if (err && !getuid())
            pam_syslog(pamh, LOG_WARNING, "Warning: Unable to lock password "
                    "into physical memory.");

    memset(&entry, 0, sizeof (struct gr_pw_entry));

    strncpy((char *)entry.rolename, username, GR_SPROLE_LEN);
    entry.rolename[GR_SPROLE_LEN - 1] = '\0';
    entry.mode = GRADM_SPROLE;
    check_acl_status(entry.mode);
    grarg = conv_user_to_kernel(&entry);
    pam_syslog (pamh, LOG_WARNING, "transmitting to kernel");
    my_transmit_to_kernel(pamh, grarg);

    pam_syslog(pamh, LOG_WARNING, "grsec role access allowed for '%s'",
                     username);


The my_transmit_to_kernel function is a copy of transmit_to_kernel, but errors are sent via pam_syslog instead of fprintf (since things die in this function)

Here is the pam config to login via sshd:

Code: Select all
auth     optional         pam_grsec.so
auth     required       pam_unix2.so


Also sshd does have the ability to auth to the kernel (afaik):

Code: Select all
subject /usr/sbin/sshd
        /etc/ld.so.cache r
        /etc/ld.so.preload r
        /etc/protocols r
        /dev/urandom r
        /lib rx
        /usr/lib rx
        /dev/grsec w
        /dev/log rwx
        +CAP_IPC_LOCK
        +CAP_NET_ADMIN


But when I login, I get this:

Code: Select all
Nov  8 00:51:18 localhost sshd[3608]: pam_grsec(sshd:auth): Attempting to auth to the role 'root'
Nov  8 00:51:18 localhost sshd[3608]: pam_grsec(sshd:auth): initting variables
Nov  8 00:51:18 localhost sshd[3608]: pam_grsec(sshd:auth): transmitting to kernel
Nov  8 00:51:18 localhost sshd[3608]: pam_grsec(sshd:auth): Invalid password.


The "Invalid password." is coming out of the my_transmit_to_kernel function ...

Any ideas? As far as I can tell, I got all the functions that are ran in gradm into this module and running in the right order ....
cormander
 
Posts: 154
Joined: Tue Jan 29, 2008 12:51 pm

Re: persist role when swithing users

Postby PaX Team » Sat Nov 08, 2008 6:02 am

cormander wrote:Also sshd does have the ability to auth to the kernel (afaik):

Code: Select all
subject /usr/sbin/sshd
i think you'll need the a subject flag to allow sshd to authenticate to the kernel. from the gradm sample policy file:
Code: Select all
a -> allow this process to talk to the /dev/grsec device
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Re: persist role when swithing users

Postby cormander » Sat Nov 08, 2008 12:21 pm

I added that and now I'm getting a little further ... but still fail with:

Code: Select all
Nov  8 09:10:00 localhost sshd[4316]: pam_grsec(sshd:auth): initting variables
Nov  8 09:10:00 localhost sshd[4316]: pam_grsec(sshd:auth): transmitting to kernel
Nov  8 09:10:00 localhost sshd[4316]: pam_grsec(sshd:auth): Invalid password.
Nov  8 09:10:00 localhost kernel: grsec: From x.x.x.x: (default:D:/usr/sbin/sshd) shutdown auth failure for /usr/sbin/sshd[sshd:4316] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/sshd[sshd:4314] uid/euid:0/0 gid/egid:0/0


This is odd because I pulled the code from the case 'n' section of parse_args, which should try non-authentication role transition .. not disable grsec.
cormander
 
Posts: 154
Joined: Tue Jan 29, 2008 12:51 pm

Re: persist role when swithing users

Postby spender » Sat Nov 08, 2008 3:04 pm

You need to have a user role for the user who will be logging into the system. For this user role, you need to add a role_transitions line (like the one for admin) which allows to transition to the non-authenticated role. You'll get the "invalid password" error if a user isn't able to transition to the given special role.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Re: persist role when swithing users

Postby cormander » Sat Nov 08, 2008 3:17 pm

Yeah I know, already have that. This is what my policy file looks like (bare-minimal for testing purposes):

Code: Select all
role admin sA
subject / rvka
        / rwcdmlxi

role root sAN
subject / rvka
        / rwcdmlxi

role default G
role_transitions admin root

subject /
        /               rwxcd
        /dev
        /dev/grsec      h
        /dev/urandom    r
        /dev/random     r
        /dev/zero       rw
        /dev/input      rw
        /dev/psaux      rw
        /dev/null       rw
        /dev/tty?       rw
        /dev/console    rw
        /dev/tty        rw
        /dev/pts        rw
        /dev/ptmx       rw
        /dev/dsp        rw
        /dev/mixer      rw
        /dev/initctl    rw
        /dev/fd0        r
        /dev/cdrom      r
        /dev/mem        h
        /dev/kmem       h
        /dev/port       h
        /etc            rx
        /etc/grsec h
        /proc           rwx
        /proc/kcore     h
        /proc/sys       r
        /root           r
        /tmp            rwcd
        /var/tmp        rwcd
        /home           rwcdCD
        /boot           h
        /sys r
        /lib rx
        /usr/lib rx
        /usr/local/sbin rx
        /usr/local/bin rx
        /sbin rx
        /bin rx
        /usr/sbin rx
        /usr/bin rx
        /usr/X11R6/bin rx

subject /sbin/klogd
        +CAP_SYS_ADMIN

subject /usr/sbin/snmpd
        +CAP_NET_ADMIN

subject /usr/sbin/sshd a
        /etc/ld.so.cache r
        /etc/ld.so.preload r
        /etc/protocols r
        /dev/urandom r
        /lib rx
        /usr/lib rx
        /dev/grsec w
        /dev/log rwx
        +CAP_IPC_LOCK
        +CAP_NET_ADMIN


I added another few lines of of debugging into the transmit_to_kernel, and one of them props up; I'm recording the value of the call to write() to the grsec device, when it compares it to: sizeof(struct gr_arg_wrapper)

Code: Select all
Nov  8 12:03:15 localhost sshd[5003]: pam_grsec(sshd:auth): Attempting to auth to the role 'root'
Nov  8 12:03:15 localhost sshd[5003]: pam_grsec(sshd:auth): initting variables
Nov  8 12:03:15 localhost sshd[5003]: pam_grsec(sshd:auth): transmitting to kernel
Nov  8 12:03:15 localhost sshd[5003]: pam_grsec(sshd:auth): wrote -1 bytes to /dev/grsec, expected 12, errno is 1
Nov  8 12:03:15 localhost sshd[5003]: pam_grsec(sshd:auth): Invalid password.
Nov  8 12:03:15 localhost kernel: grsec: From x.x.x.x: (default:D:/usr/sbin/sshd) shutdown auth failure for /usr/sbin/sshd[sshd:5003] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/sshd[sshd:5001] uid/euid:0/0 gid/egid:0/0


This return value of -1 is a failure to even write to the device, right? Am I not giving sshd enough permissions to write to the /dev/grsec device? Do I need to make a subject for /lib/security/pam_grsec.so, since that's the module that's doing this?
cormander
 
Posts: 154
Joined: Tue Jan 29, 2008 12:51 pm

Re: persist role when swithing users

Postby cormander » Sat Nov 08, 2008 4:59 pm

Not sure what I did, but it's working now! I was in the process of cleaning up the code so I could post it and have you compile it w/o having a funky setup (I downloaded the pam source, copied one of the modules and renamed a bunch of stuff). I suspect this working is a result of the cleanup of config.h (only needed one thing from there, I deleted all the rest).

It now compiles with:

Code: Select all
gcc -Igradm2 -I/usr/include -c pam_grsec.c -o pam_grsec.o
gcc -shared gradm2/*o pam_grsec.o /usr/lib/libpam.so -o /lib/security/pam_grsec.so


After I get it cleaned up some more I'll post the code, if anyone wants it.
cormander
 
Posts: 154
Joined: Tue Jan 29, 2008 12:51 pm

Re: persist role when swithing users

Postby PaX Team » Sat Nov 08, 2008 5:22 pm

cormander wrote:
Code: Select all
gcc -Igradm2 -I/usr/include -c pam_grsec.c -o pam_grsec.o
gcc -shared gradm2/*o pam_grsec.o /usr/lib/libpam.so -o /lib/security/pam_grsec.so
not sure if that's a verbatim copy of the commands, but you want -fpic when you're compiling objects for a shared library (including those of gradm itself) else you'll be producing lots of textrels not to mention that on amd64 it won't even link.
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Re: persist role when swithing users

Postby cormander » Sat Nov 08, 2008 6:58 pm

Yeah the pam makefile passes a bunch of flags to gcc, and that's one of them. I wanted to slim everything down as far as I could and get it working before I started with the optimizations and compile time options.

Thanks for the info tho. I'll put them back when I post the pam_grsec.c file.
cormander
 
Posts: 154
Joined: Tue Jan 29, 2008 12:51 pm


Return to RBAC policy development

cron