[desktop-discuss] [security-discuss] requirement for identifying a console user in RBAC

Jeffrey Hutzelman jhutz at cmu.edu
Thu Sep 6 14:34:47 PDT 2007



On Friday, August 17, 2007 11:02:42 AM +0800 Riny Qian <Riny.Qian at Sun.COM> 
wrote:

> I think the purpose here is to provide the console user with some
> authorizations/privileges so that he/she can run some admin tools
> (e.g. gnome-sys-suspend, g-p-m, poweroff) successfully. Then there
> are at least two questions to be answered:
>
> 1. Which admin tools should be provided to the console use? so that
>     which authorizations/privileges should be assigned to the console
>     user?
>
> 2. How to dynamically assign authorizations/privileges to the console
>     user?
>
> For the second question, we may add supporting library functions (e.g.
> console_role_login/console_role_logout, just like di_devperm_login/
> di_devperm_logout for console devices permission) for login programs
> (login, dtlogin, gdm) to dynamically assign required authorizations/
> privileges for the logged in console user upon login/logout.  Maybe
> there are better ideas.
>
> Another way to think about this purpose is that probably we can
> add a supporting library function like is_console_user() for admin tools
> which are identified to be used by the console user. Then these
> admin tools may need to be turned into suid root programs or something
> like that. This way requires the change to all admin tools, so it
> doesn't look good.

It sounds like you are trying to get the functionality that some Linux 
distributions get from pam_console and consolehelper.  The model is 
something like this:

When invoked as a session module, pam_console tracks logins to the console 
device(s), and records information about what user is logged in to the 
console.  It normally uses this information to provide functionality 
similar to that supported by /etc/logindevperm, but that's not really 
relevent here and could be disabled.

When invoked as an auth module, pam_console checks whether the invoking 
user is currently logged in on a console device.  It doesn't matter if the 
current tty is a console device, or even if there is one -- all that 
matters is whether the user is logged in on a console device somewhere.  If 
so, pam_console succeeds.  This mechanism can be used to short-circuit 
authentication when an application wants to be privileged.

Finally, 'consolehelper' is used as a wrapper around programs requiring 
privileges.  It runs PAM authentication using the name of the wrapped 
program as a service name, and if authentication succeeds, in then invokes 
the wrapped program in a privileged context (there is configuration 
controlling which programs can be wrapped in this way and how they are 
invoked).  This allows more or less any program to be wrapped; for example, 
on my FC5 system, /usr/bin/reboot is a symlink to consolehelper, which 
invokes /usr/sbin/reboot as root if authentication is successful.  And the 
PAM configuration for the 'reboot' service looks like this:

#%PAM-1.0
auth       sufficient   pam_rootok.so
auth       required     pam_console.so
#auth       include     system-auth
account    required     pam_permit.so


-- Jeff


More information about the desktop-discuss mailing list