apparmor/changehat/pam_apparmor/pam_apparmor.c

229 lines
5.4 KiB
C
Raw Normal View History

/* pam_apparmor module */
/*
2006-04-12 21:59:34 +00:00
* $Id$
*
* Written by Jesse Michael <jmichael@suse.de> 2006/08/24
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
* and Steve Beattie <sbeattie@suse.de> 2006/10/25
*
* Based off of pam_motd by:
* Ben Collins <bcollins@debian.org> 2005/10/04
* Michael K. Johnson <johnsonm@redhat.com> 1996/10/24
*
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <pwd.h>
#include <grp.h>
#include <syslog.h>
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
#include <errno.h>
#include <sys/apparmor.h>
#include <security/pam_ext.h>
/*
* here, we make a definition for the externally accessible function
* in this file (this definition is required for static a module
* but strongly encouraged generally) it is used to instruct the
* modules include file to define the function prototypes.
*/
#define PAM_SM_SESSION
#include <security/pam_modules.h>
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
#include "pam_apparmor.h"
#define DEBUG 0
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
static struct config default_config = {
.hat_type[0] = eGroupname,
.hat_type[1] = eDefault,
.hat_type[2] = eNoEntry,
};
/* --- session management functions (only) --- */
PAM_EXTERN int
pam_sm_close_session (pam_handle_t *pamh, int flags,
int argc, const char **argv)
{
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
return PAM_IGNORE;
}
PAM_EXTERN
int pam_sm_open_session(pam_handle_t *pamh, int flags,
int argc, const char **argv)
{
int fd, retval, pam_retval = PAM_SUCCESS;
unsigned int magic_token;
const char *user;
struct passwd *pw;
struct group *gr;
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
struct config *config = NULL;
int i;
if ((retval = get_options(pamh, &config, argc, argv)) != 0)
return retval;
if (!config)
config = &default_config;
/* grab the target user name */
retval = pam_get_user(pamh, &user, NULL);
if (retval != PAM_SUCCESS || user == NULL || *user == '\0') {
pam_syslog(pamh, LOG_ERR, "Can't determine user\n");
return PAM_USER_UNKNOWN;
}
pw = getpwnam(user);
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
if (!pw) {
pam_syslog(pamh, LOG_ERR, "Can't determine group for user %s\n", user);
return PAM_PERM_DENIED;
}
gr = getgrgid(pw->pw_gid);
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
if (!gr || !gr->gr_name) {
pam_syslog(pamh, LOG_ERR, "Can't read info for group %d\n", pw->pw_gid);
return PAM_PERM_DENIED;
}
fd = open("/dev/urandom", O_RDONLY);
if (fd < 0) {
pam_syslog(pamh, LOG_ERR, "Can't open /dev/urandom\n");
return PAM_PERM_DENIED;
}
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
/* the magic token needs to be non-zero otherwise, we won't be able
* to probe for hats */
do {
retval = read(fd, (void *) &magic_token, sizeof(magic_token));
if (retval < 0) {
pam_syslog(pamh, LOG_ERR, "Can't read from /dev/urandom\n");
return PAM_PERM_DENIED;
}
} while ((magic_token == 0) || (retval != sizeof(magic_token)));
close(fd);
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
pam_retval = PAM_SUCCESS;
for (i = 0; i < MAX_HAT_TYPES && config->hat_type[i] != eNoEntry; i++) {
const char *hat = NULL;
switch (config->hat_type[i]) {
case eGroupname:
#if DEBUG
pam_syslog(pamh, LOG_DEBUG, "Using groupname\n");
#endif
hat = gr->gr_name;
break;
case eUsername:
#if DEBUG
pam_syslog(pamh, LOG_DEBUG, "Using username\n");
#endif
hat = user;
break;
case eDefault:
#if DEBUG
pam_syslog(pamh, LOG_DEBUG, "Using DEFAULT\n");
#endif
hat = "DEFAULT";
break;
default:
pam_syslog(pamh, LOG_ERR, "Unknown value in hat table: %x\n",
config->hat_type[i]);
goto nodefault;
break;
}
retval = change_hat(hat, magic_token);
if (retval == 0) {
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
/* success, let's bail */
#if DEBUG
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
pam_syslog(pamh, LOG_DEBUG, "Successfully changed to hat '%s'\n", hat);
#endif
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
goto out;
}
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
switch (errno) {
/* case EPERM: */ /* Can't enable until ECHILD patch gets accepted, and we can
* distinguish between unconfined and confined-but-no-hats */
case EINVAL:
/* apparmor is not loaded or application is unconfined,
* stop attempting to use change_hat */
#if DEBUG
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
pam_syslog(pamh, LOG_DEBUG,
"AppArmor not loaded, or application is unconfined\n");
#endif
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
pam_retval = PAM_SUCCESS;
goto out;
break;
case ECHILD:
/* application is confined but has no hats,
* stop attempting to use change_hat */
goto nodefault;
break;
case EPERM: /* Disable when ECHILD patch gets accepted */
case EACCES:
/* failed to change into attempted hat, so we'll
* jump back out and try the next one */
break;
default:
pam_syslog(pamh, LOG_ERR, "Unknown error occurred changing to %s hat: %s\n",
hat, strerror(errno));
/* give up? */
pam_retval = PAM_SYSTEM_ERR;
goto out;
}
retval = change_hat(NULL, magic_token);
if (retval != 0) {
/* changing into the specific hat and attempting to
* jump back out both failed. that most likely
* means that either apparmor is not loaded or we
* don't have a profile loaded for this application.
* in this case, we want to allow the pam operation
* to succeed. */
goto out;
}
}
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
nodefault:
/* if we got here, we were unable to change into any of the hats
* we attempted. */
pam_syslog(pamh, LOG_ERR, "Can't change to any hat\n");
pam_retval = PAM_SESSION_ERR;
out:
/* zero out the magic token so an attacker wouldn't be able to
* just grab it out of process memory and instead would need to
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
* brute force it */
memset(&magic_token, 0, sizeof(magic_token));
This (updated) patch provides some limited configurability for pam_apparmor pam module. The default behavior is to use the user's primary groupname, and to fall back to the DEFAULT hat. You can change this behavior by appending order=type1[,type2,type3] to the pam_apparmor session line in the pam config for the application you're applying pam_apparmor to. The available types are 'user' for username, 'group' for groupname, and 'default' for DEFAULT. Thus, adding a configuration entry like: session optional pam_apparmor.so order=group,default is equivalent to the default behavior for pam_apparmor. The parse_option code got a little more complicated than I'd hoped it would be; I could have just had types by space delimited options to module, but I thought I'd leave open the possibility of adding additional options to the module ('debug' immediately comes to mind). I disabled the short-circuit that occurs if EPERM is returned by change_hat, as we can't detect that this is because there's no hats or that the application is entirely undefined; if ECHILD makes it in then we can re-enable this. I am less convinced now that pam_apparmor needs to be 'optional' than 'required'; killing the session if none of the change_hats succeeds is starting to feel like reasonable behavior. --- changehat/pam_apparmor/Makefile | 11 + changehat/pam_apparmor/README | 74 +++++++++++++ changehat/pam_apparmor/get_options.c | 157 ++++++++++++++++++++++++++++ changehat/pam_apparmor/pam_apparmor.c | 155 +++++++++++++++++++-------- changehat/pam_apparmor/pam_apparmor.h | 56 +++++++++ changehat/pam_apparmor/pam_apparmor.spec.in | 2 6 files changed, 406 insertions(+), 49 deletions(-)
2006-10-31 15:54:47 +00:00
if (config && config != &default_config)
free(config);
return pam_retval;
}
#ifdef PAM_STATIC
/* static module data */
struct pam_module _pam_apparmor_modstruct = {
"pam_apparmor",
NULL,
NULL,
NULL,
pam_sm_open_session,
pam_sm_close_session,
NULL,
};
#endif
/* end of module definition */