2006-04-11 21:52:54 +00:00
|
|
|
%{
|
|
|
|
/*
|
2007-04-11 08:12:51 +00:00
|
|
|
* Copyright (c) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007
|
|
|
|
* NOVELL (All rights reserved)
|
2010-06-04 18:57:01 -07:00
|
|
|
* Copyright (c) 2010
|
|
|
|
* Canonical, Ltd.
|
2006-04-11 21:52:54 +00:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of version 2 of the GNU General Public
|
|
|
|
* License published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
2010-06-04 18:57:01 -07:00
|
|
|
* along with this program; if not, contact Canonical, Ltd.
|
2006-04-11 21:52:54 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#define YYERROR_VERBOSE 1
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdarg.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <getopt.h>
|
|
|
|
#include <errno.h>
|
|
|
|
#include <fcntl.h>
|
|
|
|
#include <libintl.h>
|
|
|
|
#define _(s) gettext(s)
|
|
|
|
|
|
|
|
/* #define DEBUG */
|
|
|
|
|
|
|
|
#include "parser.h"
|
2010-06-04 18:47:44 -07:00
|
|
|
#include "parser_include.h"
|
2006-04-11 21:52:54 +00:00
|
|
|
#include <unistd.h>
|
|
|
|
#include <netinet/in.h>
|
|
|
|
#include <arpa/inet.h>
|
|
|
|
|
|
|
|
#include <linux/capability.h>
|
|
|
|
|
2006-11-20 05:26:25 +00:00
|
|
|
#ifndef CAP_AUDIT_WRITE
|
|
|
|
#define CAP_AUDIT_WRITE 29
|
|
|
|
#endif
|
|
|
|
#ifndef CAP_AUDIT_CONTROL
|
|
|
|
#define CAP_AUDIT_CONTROL 30
|
|
|
|
#endif
|
2009-08-20 15:27:12 +00:00
|
|
|
#ifndef CAP_SETFCAP
|
|
|
|
#define CAP_SETFCAP 31
|
|
|
|
#endif
|
|
|
|
#ifndef CAP_MAC_OVERRIDE
|
|
|
|
#define CAP_MAC_OVERRIDE 32
|
|
|
|
#endif
|
2006-04-11 21:52:54 +00:00
|
|
|
|
|
|
|
#define CIDR_32 htonl(0xffffffff)
|
|
|
|
#define CIDR_24 htonl(0xffffff00)
|
|
|
|
#define CIDR_16 htonl(0xffff0000)
|
|
|
|
#define CIDR_8 htonl(0xff000000)
|
|
|
|
|
2009-08-20 15:27:12 +00:00
|
|
|
/* undefine linux/capability.h CAP_TO_MASK */
|
|
|
|
#ifdef CAP_TO_MASK
|
|
|
|
#undef CAP_TO_MASK
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#define CAP_TO_MASK(x) (1ull << (x))
|
2006-04-11 21:52:54 +00:00
|
|
|
|
|
|
|
struct value_list {
|
|
|
|
char *value;
|
|
|
|
struct value_list *next;
|
|
|
|
};
|
|
|
|
|
|
|
|
void free_value_list(struct value_list *list);
|
2007-11-16 09:37:31 +00:00
|
|
|
struct cod_entry *do_file_rule(char *namespace, char *id, int mode,
|
2008-04-16 04:45:02 +00:00
|
|
|
char *link_id, char *nt);
|
|
|
|
|
|
|
|
void add_local_entry(struct codomain *cod);
|
|
|
|
|
|
|
|
struct codomain *do_local_profile(struct codomain *cod, char *name, int mode, int audit);
|
2006-04-11 21:52:54 +00:00
|
|
|
|
|
|
|
%}
|
|
|
|
|
|
|
|
%token TOK_ID
|
|
|
|
%token TOK_SEP
|
|
|
|
%token TOK_OPEN
|
|
|
|
%token TOK_CLOSE
|
|
|
|
%token TOK_MODE
|
|
|
|
%token TOK_END_OF_RULE
|
|
|
|
%token TOK_EQUALS
|
2007-11-16 09:37:31 +00:00
|
|
|
%token TOK_ARROW
|
2006-04-11 21:52:54 +00:00
|
|
|
%token TOK_ADD_ASSIGN
|
2008-04-06 18:55:46 +00:00
|
|
|
%token TOK_LE
|
2006-04-11 21:52:54 +00:00
|
|
|
%token TOK_SET_VAR
|
|
|
|
%token TOK_BOOL_VAR
|
|
|
|
%token TOK_VALUE
|
|
|
|
%token TOK_IF
|
|
|
|
%token TOK_ELSE
|
|
|
|
%token TOK_NOT
|
|
|
|
%token TOK_DEFINED
|
2007-06-26 21:10:28 +00:00
|
|
|
%token TOK_CHANGE_PROFILE
|
2007-07-27 20:29:47 +00:00
|
|
|
%token TOK_NETWORK
|
2007-07-27 20:48:24 +00:00
|
|
|
%token TOK_HAT
|
2007-07-27 20:55:25 +00:00
|
|
|
%token TOK_UNSAFE
|
2006-04-11 21:52:54 +00:00
|
|
|
%token TOK_COLON
|
2007-11-16 09:37:31 +00:00
|
|
|
%token TOK_LINK
|
2007-11-29 18:06:53 +00:00
|
|
|
%token TOK_OWNER
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
%token TOK_OTHER
|
2008-03-13 16:49:10 +00:00
|
|
|
%token TOK_SUBSET
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
%token TOK_AUDIT
|
|
|
|
%token TOK_DENY
|
2008-04-06 18:54:52 +00:00
|
|
|
%token TOK_PROFILE
|
2008-04-06 18:55:27 +00:00
|
|
|
%token TOK_SET
|
2008-04-09 09:03:17 +00:00
|
|
|
%token TOK_ALIAS
|
2008-04-09 09:04:08 +00:00
|
|
|
%token TOK_PTRACE
|
2006-04-11 21:52:54 +00:00
|
|
|
|
2008-04-06 18:55:46 +00:00
|
|
|
/* rlimits */
|
|
|
|
%token TOK_RLIMIT
|
|
|
|
%token TOK_SOFT_RLIMIT
|
|
|
|
%token TOK_RLIMIT_CPU
|
|
|
|
%token TOK_RLIMIT_FSIZE
|
|
|
|
%token TOK_RLIMIT_DATA
|
|
|
|
%token TOK_RLIMIT_STACK
|
|
|
|
%token TOK_RLIMIT_CORE
|
|
|
|
%token TOK_RLIMIT_RSS
|
|
|
|
%token TOK_RLIMIT_NOFILE
|
|
|
|
%token TOK_RLIMIT_OFILE
|
|
|
|
%token TOK_RLIMIT_AS
|
|
|
|
%token TOK_RLIMIT_NPROC
|
|
|
|
%token TOK_RLIMIT_MEMLOCK
|
|
|
|
%token TOK_RLIMIT_LOCKS
|
|
|
|
%token TOK_RLIMIT_SIGPENDING
|
|
|
|
%token TOK_RLIMIT_MSGQUEUE
|
|
|
|
%token TOK_RLIMIT_NICE
|
|
|
|
%token TOK_RLIMIT_RTPRIO
|
|
|
|
|
2006-04-11 21:52:54 +00:00
|
|
|
/* capabilities */
|
|
|
|
%token TOK_CAPABILITY
|
|
|
|
|
|
|
|
/* debug flag values */
|
|
|
|
%token TOK_FLAGS
|
|
|
|
%token TOK_FLAG_OPENPAREN
|
|
|
|
%token TOK_FLAG_CLOSEPAREN
|
|
|
|
%token TOK_FLAG_SEP
|
2007-11-16 09:31:33 +00:00
|
|
|
%token TOK_FLAG_ID
|
2006-04-11 21:52:54 +00:00
|
|
|
|
|
|
|
%union {
|
|
|
|
char *id;
|
2007-11-16 09:31:33 +00:00
|
|
|
char *flag_id;
|
2006-04-11 21:52:54 +00:00
|
|
|
char *mode;
|
2007-07-27 20:29:47 +00:00
|
|
|
struct aa_network_entry *network_entry;
|
2006-04-11 21:52:54 +00:00
|
|
|
struct codomain *cod;
|
|
|
|
struct cod_net_entry *net_entry;
|
|
|
|
struct cod_entry *user_entry;
|
|
|
|
struct flagval flags;
|
2007-07-27 20:47:17 +00:00
|
|
|
int fmode;
|
2009-08-20 15:27:12 +00:00
|
|
|
uint64_t cap;
|
2007-07-27 20:29:47 +00:00
|
|
|
unsigned int allowed_protocol;
|
2006-04-11 21:52:54 +00:00
|
|
|
char *set_var;
|
|
|
|
char *bool_var;
|
|
|
|
char *var_val;
|
|
|
|
struct value_list *val_list;
|
|
|
|
int boolean;
|
2008-04-16 04:45:02 +00:00
|
|
|
struct named_transition transition;
|
2006-04-11 21:52:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
%type <id> TOK_ID
|
|
|
|
%type <mode> TOK_MODE
|
2007-07-27 20:47:17 +00:00
|
|
|
%type <fmode> file_mode
|
2006-04-11 21:52:54 +00:00
|
|
|
%type <cod> profile
|
|
|
|
%type <cod> rules
|
|
|
|
%type <cod> hat
|
2008-04-16 04:45:02 +00:00
|
|
|
%type <cod> local_profile
|
2006-04-11 21:52:54 +00:00
|
|
|
%type <cod> cond_rule
|
2007-07-27 20:29:47 +00:00
|
|
|
%type <network_entry> network_rule
|
2006-04-11 21:52:54 +00:00
|
|
|
%type <user_entry> rule
|
|
|
|
%type <flags> flags
|
|
|
|
%type <flags> flagvals
|
|
|
|
%type <flags> flagval
|
2007-11-16 09:31:33 +00:00
|
|
|
%type <flag_id> TOK_FLAG_ID
|
2007-11-16 09:32:38 +00:00
|
|
|
%type <cap> caps
|
2006-04-11 21:52:54 +00:00
|
|
|
%type <cap> capability
|
2008-04-06 18:55:27 +00:00
|
|
|
%type <cap> set_caps
|
2007-06-26 21:10:28 +00:00
|
|
|
%type <user_entry> change_profile
|
2006-04-11 21:52:54 +00:00
|
|
|
%type <set_var> TOK_SET_VAR
|
|
|
|
%type <bool_var> TOK_BOOL_VAR
|
|
|
|
%type <var_val> TOK_VALUE
|
|
|
|
%type <val_list> valuelist
|
|
|
|
%type <boolean> expr
|
2007-11-16 09:30:08 +00:00
|
|
|
%type <id> id_or_var
|
2008-03-13 16:49:10 +00:00
|
|
|
%type <boolean> opt_subset_flag
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
%type <boolean> opt_audit_flag
|
|
|
|
%type <boolean> opt_owner_flag
|
2008-04-06 18:54:52 +00:00
|
|
|
%type <boolean> opt_profile_flag
|
2010-12-13 16:26:38 -08:00
|
|
|
%type <id> opt_namespace
|
2008-04-16 04:45:02 +00:00
|
|
|
%type <transition> opt_named_transition
|
|
|
|
|
2006-04-11 21:52:54 +00:00
|
|
|
%%
|
|
|
|
|
|
|
|
|
2008-11-14 16:25:44 +00:00
|
|
|
list: preamble profilelist
|
2006-04-11 21:52:54 +00:00
|
|
|
{ /* nothing */ };
|
|
|
|
|
|
|
|
profilelist: { /* nothing */ };
|
|
|
|
|
|
|
|
profilelist: profilelist profile
|
|
|
|
{
|
|
|
|
PDEBUG("Matched: list profile\n");
|
|
|
|
add_to_list($2);
|
|
|
|
};
|
|
|
|
|
2008-04-06 18:54:52 +00:00
|
|
|
opt_profile_flag: { /* nothing */ $$ = 0; }
|
|
|
|
| TOK_PROFILE { $$ = 1; }
|
2008-11-07 12:54:52 +00:00
|
|
|
| hat_start { $$ = 2; }
|
2008-04-06 18:54:52 +00:00
|
|
|
|
2010-12-13 16:26:38 -08:00
|
|
|
opt_namespace: { /* nothing */ $$ = NULL; }
|
|
|
|
| TOK_COLON TOK_ID TOK_COLON { $$ = $2; }
|
|
|
|
|
|
|
|
profile: opt_profile_flag opt_namespace TOK_ID flags TOK_OPEN rules TOK_CLOSE
|
2006-04-11 21:52:54 +00:00
|
|
|
{
|
2010-12-13 16:26:38 -08:00
|
|
|
struct codomain *cod = $6;
|
|
|
|
if ($2)
|
|
|
|
PDEBUG("Matched: id (%s://%s) open rules close\n", $2, $3);
|
|
|
|
else
|
|
|
|
PDEBUG("Matched: id (%s) open rules close\n", $3);
|
|
|
|
|
2006-04-11 21:52:54 +00:00
|
|
|
if (!cod) {
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
}
|
2007-11-16 09:18:48 +00:00
|
|
|
|
2010-12-13 16:26:38 -08:00
|
|
|
if ($3[0] != '/' && !($1 || $2))
|
|
|
|
yyerror(_("Profile names must begin with a '/', namespace or keyword 'profile' or 'hat'."));
|
2007-11-16 09:18:48 +00:00
|
|
|
|
2010-12-13 16:26:38 -08:00
|
|
|
cod->namespace = $2;
|
|
|
|
cod->name = $3;
|
|
|
|
cod->flags = $4;
|
2006-04-11 21:52:54 +00:00
|
|
|
if (force_complain)
|
2009-03-12 19:19:35 +00:00
|
|
|
cod->flags.complain = 1;
|
2008-06-09 12:00:42 +00:00
|
|
|
if ($1 == 2)
|
|
|
|
cod->flags.hat = 1;
|
2006-04-11 21:52:54 +00:00
|
|
|
|
2008-06-04 07:24:38 +00:00
|
|
|
post_process_nt_entries(cod);
|
2006-04-11 21:52:54 +00:00
|
|
|
PDEBUG("%s: flags='%s%s'\n",
|
2008-04-06 18:54:52 +00:00
|
|
|
$2,
|
2006-04-11 21:52:54 +00:00
|
|
|
cod->flags.complain ? "complain, " : "",
|
|
|
|
cod->flags.audit ? "audit" : "");
|
|
|
|
|
|
|
|
$$ = cod;
|
|
|
|
};
|
|
|
|
|
2008-11-14 16:25:44 +00:00
|
|
|
preamble: { /* nothing */ }
|
|
|
|
| preamble alias { /* nothing */ };
|
|
|
|
| preamble varassign { /* nothing */ };
|
2008-04-09 09:03:17 +00:00
|
|
|
|
|
|
|
alias: TOK_ALIAS TOK_ID TOK_ARROW TOK_ID TOK_END_OF_RULE
|
|
|
|
{
|
|
|
|
if (!new_alias($2, $4))
|
|
|
|
yyerror(_("Failed to create alias %s -> %s\n"), $2, $4);
|
|
|
|
free($2);
|
|
|
|
free($4);
|
|
|
|
};
|
|
|
|
|
2006-04-11 21:52:54 +00:00
|
|
|
varassign: TOK_SET_VAR TOK_EQUALS valuelist
|
|
|
|
{
|
|
|
|
struct value_list *list = $3;
|
|
|
|
char *var_name = process_var($1);
|
|
|
|
int err;
|
|
|
|
if (!list || !list->value)
|
|
|
|
yyerror("Assert: valuelist returned NULL");
|
|
|
|
PDEBUG("Matched: set assignment for (%s)\n", $1);
|
|
|
|
err = new_set_var(var_name, list->value);
|
|
|
|
if (err) {
|
|
|
|
yyerror("variable %s was previously declared", $1);
|
|
|
|
/* FIXME: it'd be handy to report the previous location */
|
|
|
|
}
|
|
|
|
for (list = list->next; list; list = list->next) {
|
|
|
|
err = add_set_value(var_name, list->value);
|
|
|
|
if (err)
|
|
|
|
yyerror("Error adding %s to set var %s",
|
|
|
|
list->value, $1);
|
|
|
|
}
|
|
|
|
free_value_list($3);
|
|
|
|
free(var_name);
|
|
|
|
free($1);
|
|
|
|
}
|
|
|
|
|
|
|
|
varassign: TOK_SET_VAR TOK_ADD_ASSIGN valuelist
|
|
|
|
{
|
|
|
|
struct value_list *list = $3;
|
|
|
|
char *var_name = process_var($1);
|
|
|
|
int err;
|
|
|
|
if (!list || !list->value)
|
|
|
|
yyerror("Assert: valuelist returned NULL");
|
|
|
|
PDEBUG("Matched: additive assignment for (%s)\n", $1);
|
|
|
|
/* do the first one outside the loop, subsequent
|
|
|
|
* failures are indicative of symtab failures */
|
|
|
|
err = add_set_value(var_name, list->value);
|
|
|
|
if (err) {
|
|
|
|
yyerror("variable %s was not previously declared, but is being assigned additional values", $1);
|
|
|
|
}
|
|
|
|
for (list = list->next; list; list = list->next) {
|
|
|
|
err = add_set_value(var_name, list->value);
|
|
|
|
if (err)
|
|
|
|
yyerror("Error adding %s to set var %s",
|
|
|
|
list->value, $1);
|
|
|
|
}
|
|
|
|
free_value_list($3);
|
|
|
|
free(var_name);
|
|
|
|
free($1);
|
|
|
|
}
|
|
|
|
|
|
|
|
varassign: TOK_BOOL_VAR TOK_EQUALS TOK_VALUE
|
|
|
|
{
|
|
|
|
int boolean, err;
|
|
|
|
char *var_name = process_var($1);
|
|
|
|
PDEBUG("Matched: boolean assignment (%s) to %s\n", $1, $3);
|
|
|
|
boolean = str_to_boolean($3);
|
|
|
|
if (boolean == -1) {
|
|
|
|
yyerror("Invalid boolean assignment for (%s): %s is not true or false",
|
|
|
|
$1, $3);
|
|
|
|
}
|
|
|
|
err = add_boolean_var(var_name, boolean);
|
|
|
|
if (err) {
|
|
|
|
yyerror("variable %s was previously declared", $1);
|
|
|
|
/* FIXME: it'd be handy to report the previous location */
|
|
|
|
}
|
|
|
|
free(var_name);
|
|
|
|
free($1);
|
|
|
|
free($3);
|
|
|
|
}
|
|
|
|
|
|
|
|
valuelist: TOK_VALUE
|
|
|
|
{
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
struct value_list *new = calloc(1, sizeof(struct value_list));
|
2006-04-11 21:52:54 +00:00
|
|
|
if (!new)
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
PDEBUG("Matched: value (%s)\n", $1);
|
|
|
|
|
|
|
|
new->value = $1;
|
|
|
|
new->next = NULL;
|
|
|
|
$$ = new;
|
|
|
|
}
|
|
|
|
|
|
|
|
valuelist: valuelist TOK_VALUE
|
|
|
|
{
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
struct value_list *new = calloc(1, sizeof(struct value_list));
|
2006-04-11 21:52:54 +00:00
|
|
|
if (!new)
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
PDEBUG("Matched: value (%s)\n", $1);
|
|
|
|
|
|
|
|
new->value = $2;
|
|
|
|
new->next = $1;
|
|
|
|
$$ = new;
|
|
|
|
}
|
|
|
|
|
|
|
|
flags: { /* nothing */
|
2010-02-17 12:21:52 -08:00
|
|
|
struct flagval fv = { 0, 0, 0, 0 };
|
2006-04-11 21:52:54 +00:00
|
|
|
|
|
|
|
$$ = fv;
|
|
|
|
};
|
|
|
|
|
|
|
|
flags: TOK_FLAGS TOK_EQUALS TOK_FLAG_OPENPAREN flagvals TOK_FLAG_CLOSEPAREN
|
|
|
|
{
|
|
|
|
$$ = $4;
|
|
|
|
};
|
|
|
|
|
2007-11-16 09:31:33 +00:00
|
|
|
flags: TOK_FLAG_OPENPAREN flagvals TOK_FLAG_CLOSEPAREN
|
|
|
|
{
|
|
|
|
$$ = $2;
|
|
|
|
}
|
|
|
|
|
2006-04-11 21:52:54 +00:00
|
|
|
flagvals: flagvals TOK_FLAG_SEP flagval
|
|
|
|
{
|
|
|
|
$1.complain = $1.complain || $3.complain;
|
|
|
|
$1.audit = $1.audit || $3.audit;
|
2010-02-17 12:21:52 -08:00
|
|
|
$1.path = $1.path | $3.path;
|
|
|
|
if (($1.path & (PATH_CHROOT_REL | PATH_NS_REL)) ==
|
|
|
|
(PATH_CHROOT_REL | PATH_NS_REL))
|
|
|
|
yyerror(_("Profile flag chroot_relative conflicts with namespace_relative"));
|
|
|
|
|
|
|
|
if (($1.path & (PATH_MEDIATE_DELETED | PATH_DELEGATE_DELETED)) ==
|
|
|
|
(PATH_MEDIATE_DELETED | PATH_DELEGATE_DELETED))
|
|
|
|
yyerror(_("Profile flag mediate_deleted conflicts with delegate_deleted"));
|
|
|
|
if (($1.path & (PATH_ATTACH | PATH_NO_ATTACH)) ==
|
|
|
|
(PATH_ATTACH | PATH_NO_ATTACH))
|
|
|
|
yyerror(_("Profile flag attach_disconnected conflicts with no_attach_disconnected"));
|
|
|
|
if (($1.path & (PATH_CHROOT_NSATTACH | PATH_CHROOT_NO_ATTACH)) ==
|
|
|
|
(PATH_CHROOT_NSATTACH | PATH_CHROOT_NO_ATTACH))
|
|
|
|
yyerror(_("Profile flag chroot_attach conflicts with chroot_no_attach"));
|
2006-04-11 21:52:54 +00:00
|
|
|
|
|
|
|
$$ = $1;
|
|
|
|
};
|
|
|
|
|
|
|
|
flagvals: flagval
|
|
|
|
{
|
|
|
|
$$ = $1;
|
|
|
|
};
|
|
|
|
|
2007-11-16 09:31:33 +00:00
|
|
|
flagval: TOK_FLAG_ID
|
2006-04-11 21:52:54 +00:00
|
|
|
{
|
2010-07-26 09:22:45 -07:00
|
|
|
struct flagval fv = { 0, 0, 0, 0 };
|
2007-11-16 09:31:33 +00:00
|
|
|
if (strcmp($1, "debug") == 0) {
|
|
|
|
yyerror(_("Profile flag 'debug' is no longer valid."));
|
|
|
|
} else if (strcmp($1, "complain") == 0) {
|
|
|
|
fv.complain = 1;
|
|
|
|
} else if (strcmp($1, "audit") == 0) {
|
|
|
|
fv.audit = 1;
|
2010-02-17 12:21:52 -08:00
|
|
|
} else if (strcmp($1, "chroot_relative") == 0) {
|
|
|
|
fv.path |= PATH_CHROOT_REL;
|
|
|
|
} else if (strcmp($1, "namespace_relative") == 0) {
|
|
|
|
fv.path |= PATH_NS_REL;
|
|
|
|
} else if (strcmp($1, "mediate_deleted") == 0) {
|
|
|
|
fv.path |= PATH_MEDIATE_DELETED;
|
|
|
|
} else if (strcmp($1, "delegate_deleted") == 0) {
|
|
|
|
fv.path |= PATH_DELEGATE_DELETED;
|
|
|
|
} else if (strcmp($1, "attach_disconnected") == 0) {
|
|
|
|
fv.path |= PATH_ATTACH;
|
|
|
|
} else if (strcmp($1, "no_attach_disconnected") == 0) {
|
|
|
|
fv.path |= PATH_NO_ATTACH;
|
|
|
|
} else if (strcmp($1, "chroot_attach") == 0) {
|
|
|
|
fv.path |= PATH_CHROOT_NSATTACH;
|
|
|
|
} else if (strcmp($1, "chroot_no_attach") == 0) {
|
|
|
|
fv.path |= PATH_CHROOT_NO_ATTACH;
|
2007-11-16 09:31:33 +00:00
|
|
|
} else {
|
|
|
|
yyerror(_("Invalid profile flag: %s."), $1);
|
|
|
|
}
|
|
|
|
free($1);
|
2006-04-11 21:52:54 +00:00
|
|
|
$$ = fv;
|
|
|
|
};
|
|
|
|
|
2008-03-13 16:49:10 +00:00
|
|
|
opt_subset_flag: { /* nothing */ $$ = 0; }
|
|
|
|
| TOK_SUBSET { $$ = 1; }
|
2008-04-09 09:02:51 +00:00
|
|
|
| TOK_LE { $$ = 1; }
|
2008-03-13 16:49:10 +00:00
|
|
|
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
opt_audit_flag: { /* nothing */ $$ = 0; }
|
|
|
|
| TOK_AUDIT { $$ = 1; };
|
|
|
|
|
|
|
|
opt_owner_flag: { /* nothing */ $$ = 0; }
|
|
|
|
| TOK_OWNER { $$ = 1; };
|
|
|
|
| TOK_OTHER { $$ = 2; };
|
|
|
|
|
2006-04-11 21:52:54 +00:00
|
|
|
rules: { /* nothing */
|
|
|
|
struct codomain *cod = NULL;
|
|
|
|
cod = (struct codomain *) calloc(1, sizeof(struct codomain));
|
|
|
|
if (!cod) {
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
}
|
|
|
|
|
|
|
|
$$ = cod;
|
|
|
|
};
|
|
|
|
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
/* can't fold TOK_DENY in as opt_deny_flag as it messes up the generated
|
|
|
|
* parser, even though it shouldn't
|
|
|
|
*/
|
|
|
|
rules: rules opt_audit_flag TOK_DENY opt_owner_flag rule
|
2006-04-11 21:52:54 +00:00
|
|
|
{
|
|
|
|
PDEBUG("matched: rules rule\n");
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
PDEBUG("rules rule: (%s)\n", $5->name);
|
|
|
|
if (!$5)
|
|
|
|
yyerror(_("Assert: `rule' returned NULL."));
|
|
|
|
$5->deny = 1;
|
|
|
|
if (($5->mode & AA_EXEC_BITS) && ($5->mode & ALL_AA_EXEC_TYPE))
|
|
|
|
yyerror(_("Invalid mode, in deny rules 'x' must not be preceded by exec qualifier 'i', 'p', or 'u'"));
|
|
|
|
|
|
|
|
if ($4 == 1)
|
2008-04-09 09:04:08 +00:00
|
|
|
$5->mode &= (AA_USER_PERMS | AA_SHARED_PERMS | AA_USER_PTRACE);
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
else if ($4 == 2)
|
2008-04-09 09:04:08 +00:00
|
|
|
$5->mode &= (AA_OTHER_PERMS | AA_SHARED_PERMS | AA_OTHER_PTRACE);
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
/* only set audit ctl quieting if the rule is not audited */
|
2006-04-11 21:52:54 +00:00
|
|
|
if (!$2)
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
$5->audit = $5->mode & ~ALL_AA_EXEC_TYPE;
|
|
|
|
|
|
|
|
add_entry_to_policy($1, $5);
|
|
|
|
$$ = $1;
|
|
|
|
};
|
|
|
|
|
|
|
|
rules: rules opt_audit_flag opt_owner_flag rule
|
|
|
|
{
|
|
|
|
PDEBUG("matched: rules rule\n");
|
|
|
|
PDEBUG("rules rule: (%s)\n", $4->name);
|
|
|
|
if (!$4)
|
2006-04-11 21:52:54 +00:00
|
|
|
yyerror(_("Assert: `rule' returned NULL."));
|
2008-04-18 00:40:40 +00:00
|
|
|
if (($4->mode & AA_EXEC_BITS) &&
|
|
|
|
!($4->mode & ALL_AA_EXEC_TYPE) &&
|
|
|
|
!($4->nt_name))
|
|
|
|
yyerror(_("Invalid mode, 'x' must be preceded by exec qualifier 'i', 'p', 'c', or 'u'"));
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
|
|
|
|
if ($3 == 1)
|
2008-04-09 09:04:08 +00:00
|
|
|
$4->mode &= (AA_USER_PERMS | AA_SHARED_PERMS | AA_USER_PTRACE);
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
else if ($3 == 2)
|
2008-04-09 09:04:08 +00:00
|
|
|
$4->mode &= (AA_OTHER_PERMS | AA_SHARED_PERMS | AA_OTHER_PTRACE);
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
if ($2)
|
|
|
|
$4->audit = $4->mode & ~ALL_AA_EXEC_TYPE;
|
|
|
|
|
|
|
|
add_entry_to_policy($1, $4);
|
2006-04-11 21:52:54 +00:00
|
|
|
$$ = $1;
|
|
|
|
};
|
2007-12-20 12:55:27 +00:00
|
|
|
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
rules: rules opt_audit_flag opt_owner_flag TOK_OPEN rules TOK_CLOSE
|
2007-11-29 18:06:53 +00:00
|
|
|
{
|
|
|
|
struct cod_entry *entry, *tmp;
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
PDEBUG("matched: audit block\n");
|
|
|
|
list_for_each_safe($5->entries, entry, tmp) {
|
|
|
|
entry->next = NULL;
|
|
|
|
if (entry->mode & AA_EXEC_BITS) {
|
|
|
|
if (entry->deny &&
|
|
|
|
(entry->mode & ALL_AA_EXEC_TYPE))
|
|
|
|
yyerror(_("Invalid mode, in deny rules 'x' must not be preceded by exec qualifier 'i', 'p', or 'u'"));
|
|
|
|
else if (!entry->deny &&
|
|
|
|
!(entry->mode & ALL_AA_EXEC_TYPE))
|
|
|
|
yyerror(_("Invalid mode, 'x' must be preceded by exec qualifier 'i', 'p', or 'u'"));
|
2007-11-29 18:06:53 +00:00
|
|
|
}
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
if ($3 == 1)
|
2008-04-09 23:56:31 +00:00
|
|
|
entry->mode &= (AA_USER_PERMS | AA_SHARED_PERMS | AA_USER_PTRACE);
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
else if ($3 == 2)
|
2008-04-09 23:56:31 +00:00
|
|
|
entry->mode &= (AA_OTHER_PERMS | AA_SHARED_PERMS | AA_OTHER_PTRACE);
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
|
|
|
|
if ($2 && !entry->deny)
|
|
|
|
entry->audit = entry->mode & ~ALL_AA_EXEC_TYPE;
|
|
|
|
else if (!$2 && entry->deny)
|
|
|
|
entry->audit = entry->mode & ~ALL_AA_EXEC_TYPE;
|
|
|
|
add_entry_to_policy($1, entry);
|
2007-11-29 18:06:53 +00:00
|
|
|
}
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
$5->entries = NULL;
|
|
|
|
// fix me transfer rules and free sub codomain
|
|
|
|
free_policy($5);
|
2007-11-29 18:06:53 +00:00
|
|
|
$$ = $1;
|
|
|
|
};
|
2006-04-11 21:52:54 +00:00
|
|
|
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
rules: rules opt_audit_flag TOK_DENY network_rule
|
2007-07-27 20:29:47 +00:00
|
|
|
{
|
|
|
|
struct aa_network_entry *entry, *tmp;
|
|
|
|
|
|
|
|
PDEBUG("Matched: network rule\n");
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
if (!$4)
|
2007-07-27 20:29:47 +00:00
|
|
|
yyerror(_("Assert: `network_rule' return invalid protocol."));
|
|
|
|
if (!$1->network_allowed) {
|
2009-07-24 17:24:41 +00:00
|
|
|
$1->network_allowed = calloc(get_af_max(),
|
2007-07-27 20:29:47 +00:00
|
|
|
sizeof(unsigned int));
|
2009-07-24 17:24:41 +00:00
|
|
|
$1->audit_network = calloc(get_af_max(),
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
sizeof(unsigned int));
|
2009-07-24 17:24:41 +00:00
|
|
|
$1->deny_network = calloc(get_af_max(),
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
sizeof(unsigned int));
|
2009-07-24 17:24:41 +00:00
|
|
|
$1->quiet_network = calloc(get_af_max(),
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
sizeof(unsigned int));
|
|
|
|
if (!$1->network_allowed || !$1->audit_network ||
|
|
|
|
!$1->deny_network || !$1->quiet_network)
|
2007-07-27 20:29:47 +00:00
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
}
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
list_for_each_safe($4, entry, tmp) {
|
|
|
|
if (entry->type > SOCK_PACKET) {
|
|
|
|
/* setting mask instead of a bit */
|
|
|
|
$1->deny_network[entry->family] |= entry->type;
|
|
|
|
if (!$2)
|
|
|
|
$1->quiet_network[entry->family] |= entry->type;
|
|
|
|
|
|
|
|
} else {
|
|
|
|
$1->deny_network[entry->family] |= 1 << entry->type;
|
|
|
|
if (!$2)
|
|
|
|
$1->quiet_network[entry->family] |= 1 << entry->type;
|
|
|
|
}
|
|
|
|
free(entry);
|
|
|
|
}
|
|
|
|
|
2008-11-18 17:33:38 +00:00
|
|
|
$$ = $1;
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
rules: rules opt_audit_flag network_rule
|
|
|
|
{
|
|
|
|
struct aa_network_entry *entry, *tmp;
|
|
|
|
|
|
|
|
PDEBUG("Matched: network rule\n");
|
|
|
|
if (!$3)
|
|
|
|
yyerror(_("Assert: `network_rule' return invalid protocol."));
|
|
|
|
if (!$1->network_allowed) {
|
2009-07-24 17:24:41 +00:00
|
|
|
$1->network_allowed = calloc(get_af_max(),
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
sizeof(unsigned int));
|
2009-07-24 17:24:41 +00:00
|
|
|
$1->audit_network = calloc(get_af_max(),
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
sizeof(unsigned int));
|
2009-07-24 17:24:41 +00:00
|
|
|
$1->deny_network = calloc(get_af_max(),
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
sizeof(unsigned int));
|
2009-07-24 17:24:41 +00:00
|
|
|
$1->quiet_network = calloc(get_af_max(),
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
sizeof(unsigned int));
|
|
|
|
if (!$1->network_allowed || !$1->audit_network ||
|
|
|
|
!$1->deny_network || !$1->quiet_network)
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
}
|
|
|
|
list_for_each_safe($3, entry, tmp) {
|
2007-07-27 20:29:47 +00:00
|
|
|
if (entry->type > SOCK_PACKET) {
|
|
|
|
/* setting mask instead of a bit */
|
|
|
|
$1->network_allowed[entry->family] |= entry->type;
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
if ($2)
|
|
|
|
$1->audit_network[entry->family] |= entry->type;
|
|
|
|
|
2007-07-27 20:29:47 +00:00
|
|
|
} else {
|
|
|
|
$1->network_allowed[entry->family] |= 1 << entry->type;
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
if ($2)
|
|
|
|
$1->audit_network[entry->family] |= 1 << entry->type;
|
2007-07-27 20:29:47 +00:00
|
|
|
}
|
|
|
|
free(entry);
|
|
|
|
}
|
|
|
|
|
2008-11-18 17:33:38 +00:00
|
|
|
$$ = $1;
|
2007-07-27 20:29:47 +00:00
|
|
|
}
|
|
|
|
|
2007-06-26 21:10:28 +00:00
|
|
|
rules: rules change_profile
|
|
|
|
{
|
|
|
|
PDEBUG("matched: rules change_profile\n");
|
|
|
|
PDEBUG("rules change_profile: (%s)\n", $2->name);
|
|
|
|
if (!$2)
|
|
|
|
yyerror(_("Assert: `change_profile' returned NULL."));
|
|
|
|
add_entry_to_policy($1, $2);
|
|
|
|
$$ = $1;
|
|
|
|
};
|
|
|
|
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
rules: rules opt_audit_flag TOK_DENY capability
|
|
|
|
{
|
|
|
|
$1->deny_caps |= $4;
|
|
|
|
if (!$2)
|
|
|
|
$1->quiet_caps |= $4;
|
|
|
|
$$ = $1;
|
|
|
|
};
|
|
|
|
|
|
|
|
rules: rules opt_audit_flag capability
|
2006-04-11 21:52:54 +00:00
|
|
|
{
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
$1->capabilities |= $3;
|
|
|
|
if ($2)
|
|
|
|
$1->audit_caps |= $3;
|
2006-04-11 21:52:54 +00:00
|
|
|
$$ = $1;
|
|
|
|
};
|
|
|
|
|
2008-04-06 18:55:27 +00:00
|
|
|
rules: rules set_caps
|
|
|
|
{
|
|
|
|
$1->set_caps |= $2;
|
|
|
|
$$ = $1;
|
|
|
|
};
|
|
|
|
|
2006-04-11 21:52:54 +00:00
|
|
|
rules: rules hat
|
|
|
|
{
|
|
|
|
PDEBUG("Matched: hat rule\n");
|
|
|
|
if (!$2)
|
|
|
|
yyerror(_("Assert: 'hat rule' returned NULL."));
|
|
|
|
add_hat_to_policy($1, $2);
|
|
|
|
$$ = $1;
|
|
|
|
};
|
|
|
|
|
2008-04-16 04:45:02 +00:00
|
|
|
rules: rules local_profile
|
|
|
|
{
|
|
|
|
PDEBUG("Matched: hat rule\n");
|
|
|
|
if (!$2)
|
|
|
|
yyerror(_("Assert: 'local_profile rule' returned NULL."));
|
|
|
|
add_hat_to_policy($1, $2);
|
|
|
|
add_local_entry($2);
|
|
|
|
$$ = $1;
|
|
|
|
};
|
|
|
|
|
2006-04-11 21:52:54 +00:00
|
|
|
rules: rules cond_rule
|
|
|
|
{
|
|
|
|
PDEBUG("Matched: conditional rules\n");
|
|
|
|
$$ = merge_policy($1, $2);
|
|
|
|
}
|
|
|
|
|
2008-04-06 18:55:46 +00:00
|
|
|
rules: rules TOK_SET TOK_RLIMIT TOK_ID TOK_LE TOK_VALUE TOK_END_OF_RULE
|
|
|
|
{
|
|
|
|
rlim_t value = RLIM_INFINITY;
|
|
|
|
long long tmp;
|
|
|
|
char *end;
|
|
|
|
|
|
|
|
int limit = get_rlimit($4);
|
|
|
|
if (limit == -1)
|
|
|
|
yyerror("INVALID RLIMIT '%s'\n", $4);
|
|
|
|
|
|
|
|
if (strcmp($6, "infinity") == 0) {
|
|
|
|
value = RLIM_INFINITY;
|
|
|
|
} else {
|
|
|
|
tmp = strtoll($6, &end, 0);
|
|
|
|
switch (limit) {
|
|
|
|
case RLIMIT_CPU:
|
2008-04-07 04:26:02 +00:00
|
|
|
yyerror("RLIMIT '%s' is currently unsupported\n", $4);
|
|
|
|
break;
|
2008-04-06 18:55:46 +00:00
|
|
|
case RLIMIT_NOFILE:
|
|
|
|
case RLIMIT_NPROC:
|
|
|
|
case RLIMIT_LOCKS:
|
|
|
|
case RLIMIT_SIGPENDING:
|
2008-06-09 21:17:41 +00:00
|
|
|
#ifdef RLIMIT_RTPRIO
|
2008-04-06 18:55:46 +00:00
|
|
|
case RLIMIT_RTPRIO:
|
|
|
|
if ($6 == end || *end != '\0' || tmp < 0)
|
|
|
|
yyerror("RLIMIT '%s' invalid value %s\n", $4, $6);
|
|
|
|
value = tmp;
|
|
|
|
break;
|
2008-06-09 21:17:41 +00:00
|
|
|
#endif
|
|
|
|
#ifdef RLIMIT_NICE
|
2008-04-06 18:55:46 +00:00
|
|
|
case RLIMIT_NICE:
|
|
|
|
if ($6 == end || *end != '\0')
|
|
|
|
yyerror("RLIMIT '%s' invalid value %s\n", $4, $6);
|
|
|
|
if (tmp < -20 || tmp > 19)
|
|
|
|
yyerror("RLIMIT '%s' out of range (-20 .. 19) %d\n", $4, tmp);
|
|
|
|
value = tmp + 20;
|
|
|
|
break;
|
2008-06-09 21:17:41 +00:00
|
|
|
#endif
|
2008-04-06 18:55:46 +00:00
|
|
|
case RLIMIT_FSIZE:
|
|
|
|
case RLIMIT_DATA:
|
|
|
|
case RLIMIT_STACK:
|
|
|
|
case RLIMIT_CORE:
|
|
|
|
case RLIMIT_RSS:
|
|
|
|
case RLIMIT_AS:
|
|
|
|
case RLIMIT_MEMLOCK:
|
|
|
|
case RLIMIT_MSGQUEUE:
|
|
|
|
if ($6 == end || tmp < 0)
|
|
|
|
yyerror("RLIMIT '%s' invalid value %s\n", $4, $6);
|
|
|
|
if (strcmp(end, "K") == 0) {
|
|
|
|
tmp *= 1024;
|
|
|
|
} else if (strcmp(end, "M") == 0) {
|
|
|
|
tmp *= 1024*1024;
|
|
|
|
} else if (strcmp(end, "G") == 0) {
|
|
|
|
tmp *= 1024*1024*1024;
|
|
|
|
} else if (*end != '\0') {
|
|
|
|
yyerror("RLIMIT '%s' invalid value %s\n", $4, $6);
|
|
|
|
}
|
|
|
|
value = tmp;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
yyerror("Unknown RLIMIT %d\n", $4);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
$1->rlimits.specified |= 1 << limit;
|
|
|
|
$1->rlimits.limits[limit] = value;
|
|
|
|
free($4);
|
|
|
|
free($6);
|
|
|
|
$$ = $1;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2006-04-11 21:52:54 +00:00
|
|
|
cond_rule: TOK_IF expr TOK_OPEN rules TOK_CLOSE
|
|
|
|
{
|
|
|
|
struct codomain *ret = NULL;
|
|
|
|
PDEBUG("Matched: found conditional rules\n");
|
|
|
|
if ($2) {
|
|
|
|
ret = $4;
|
|
|
|
} else {
|
|
|
|
free_policy($4);
|
|
|
|
}
|
|
|
|
$$ = ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
cond_rule: TOK_IF expr TOK_OPEN rules TOK_CLOSE TOK_ELSE TOK_OPEN rules TOK_CLOSE
|
|
|
|
{
|
|
|
|
struct codomain *ret = NULL;
|
|
|
|
PDEBUG("Matched: found conditional else rules\n");
|
|
|
|
if ($2) {
|
|
|
|
ret = $4;
|
|
|
|
free_policy($8);
|
|
|
|
} else {
|
|
|
|
ret = $8;
|
|
|
|
free_policy($4);
|
|
|
|
}
|
|
|
|
$$ = ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
cond_rule: TOK_IF expr TOK_OPEN rules TOK_CLOSE TOK_ELSE cond_rule
|
|
|
|
{
|
|
|
|
struct codomain *ret = NULL;
|
|
|
|
PDEBUG("Matched: found conditional else-if rules\n");
|
|
|
|
if ($2) {
|
|
|
|
ret = $4;
|
|
|
|
free_policy($7);
|
|
|
|
} else {
|
|
|
|
ret = $7;
|
|
|
|
free_policy($4);
|
|
|
|
}
|
|
|
|
$$ = ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
expr: TOK_NOT expr
|
|
|
|
{
|
|
|
|
$$ = !$2;
|
|
|
|
}
|
|
|
|
|
|
|
|
expr: TOK_BOOL_VAR
|
|
|
|
{
|
|
|
|
char *var_name = process_var($1);
|
|
|
|
int boolean = get_boolean_var(var_name);
|
|
|
|
PDEBUG("Matched: boolean expr %s value: %d\n", $1, boolean);
|
|
|
|
if (boolean < 0) {
|
|
|
|
/* FIXME check for set var */
|
|
|
|
yyerror(_("Unset boolean variable %s used in if-expression"),
|
|
|
|
$1);
|
|
|
|
}
|
|
|
|
$$ = boolean;
|
|
|
|
free(var_name);
|
|
|
|
free($1);
|
|
|
|
}
|
|
|
|
|
|
|
|
expr: TOK_DEFINED TOK_SET_VAR
|
|
|
|
{
|
|
|
|
char *var_name = process_var($2);
|
|
|
|
void *set_value = get_set_var(var_name);
|
|
|
|
PDEBUG("Matched: defined set expr %s value %lx\n", $2, (long) set_value);
|
|
|
|
$$ = !! (long) set_value;
|
|
|
|
free(var_name);
|
|
|
|
free($2);
|
|
|
|
}
|
|
|
|
|
|
|
|
expr: TOK_DEFINED TOK_BOOL_VAR
|
|
|
|
{
|
|
|
|
char *var_name = process_var($2);
|
|
|
|
int boolean = get_boolean_var(var_name);
|
|
|
|
PDEBUG("Matched: defined set expr %s value %d\n", $2, boolean);
|
|
|
|
$$ = (boolean != -1);
|
|
|
|
free(var_name);
|
|
|
|
free($2);
|
|
|
|
}
|
|
|
|
|
2007-11-16 09:30:08 +00:00
|
|
|
id_or_var: TOK_ID { $$ = $1; }
|
|
|
|
id_or_var: TOK_SET_VAR { $$ = $1; };
|
2006-04-11 21:52:54 +00:00
|
|
|
|
2008-04-16 04:45:02 +00:00
|
|
|
opt_named_transition:
|
|
|
|
{ /* nothing */
|
|
|
|
$$.present = 0;
|
|
|
|
$$.namespace = NULL;
|
|
|
|
$$.name = NULL;
|
|
|
|
}
|
|
|
|
| TOK_ARROW id_or_var
|
|
|
|
{
|
|
|
|
$$.present = 1;
|
|
|
|
$$.namespace = NULL;
|
|
|
|
$$.name = $2;
|
|
|
|
}
|
|
|
|
| TOK_ARROW TOK_COLON id_or_var TOK_COLON id_or_var
|
|
|
|
{
|
|
|
|
$$.present = 1;
|
|
|
|
$$.namespace = $3;
|
|
|
|
$$.name = $5;
|
|
|
|
};
|
|
|
|
|
|
|
|
rule: id_or_var file_mode opt_named_transition TOK_END_OF_RULE
|
2006-04-11 21:52:54 +00:00
|
|
|
{
|
2008-04-16 04:45:02 +00:00
|
|
|
$$ = do_file_rule($3.namespace, $1, $2, NULL, $3.name);
|
2007-07-27 20:55:25 +00:00
|
|
|
};
|
|
|
|
|
2008-04-16 04:45:02 +00:00
|
|
|
rule: file_mode opt_subset_flag id_or_var opt_named_transition TOK_END_OF_RULE
|
2007-07-27 20:55:25 +00:00
|
|
|
{
|
2008-04-16 04:45:02 +00:00
|
|
|
if ($2 && ($1 & ~AA_LINK_BITS))
|
|
|
|
yyerror(_("subset can only be used with link rules."));
|
|
|
|
if ($4.present && ($1 & AA_LINK_BITS) && ($1 & AA_EXEC_BITS))
|
|
|
|
yyerror(_("link and exec perms conflict on a file rule using ->"));
|
|
|
|
if ($4.present && $4.namespace && ($1 & AA_LINK_BITS))
|
|
|
|
yyerror(_("link perms are not allowed on a named profile transition.\n"));
|
|
|
|
if (($1 & AA_LINK_BITS)) {
|
|
|
|
$$ = do_file_rule(NULL, $3, $1 & ~ALL_AA_EXEC_UNSAFE,
|
|
|
|
$4.name, NULL);
|
|
|
|
$$->subset = $2;
|
|
|
|
|
|
|
|
} else {
|
|
|
|
$$ = do_file_rule($4.namespace, $3, $1 & ~ALL_AA_EXEC_UNSAFE, NULL, $4.name);
|
|
|
|
}
|
2007-07-27 20:55:25 +00:00
|
|
|
};
|
|
|
|
|
2008-04-16 04:45:02 +00:00
|
|
|
rule: TOK_UNSAFE file_mode id_or_var opt_named_transition TOK_END_OF_RULE
|
2007-07-27 20:55:25 +00:00
|
|
|
{
|
2008-03-13 16:46:53 +00:00
|
|
|
int mode = (($2 & AA_EXEC_BITS) << 8) & ALL_AA_EXEC_UNSAFE;
|
2008-04-16 04:45:02 +00:00
|
|
|
|
2007-11-16 09:35:31 +00:00
|
|
|
if (!($2 & AA_EXEC_BITS))
|
2007-07-27 20:55:25 +00:00
|
|
|
yyerror(_("unsafe rule missing exec permissions"));
|
2008-04-16 04:45:02 +00:00
|
|
|
|
|
|
|
if ($4.present && ($2 & AA_LINK_BITS))
|
2008-09-12 06:52:39 +00:00
|
|
|
yyerror(_("link perms are not allowed on a named profile transition.\n"));
|
2008-04-16 04:45:02 +00:00
|
|
|
|
|
|
|
$$ = do_file_rule($4.namespace, $3,
|
|
|
|
($2 & ~ALL_AA_EXEC_UNSAFE) | mode,
|
|
|
|
NULL, $4.name);
|
2007-07-27 20:55:25 +00:00
|
|
|
};
|
|
|
|
|
2007-11-16 09:30:08 +00:00
|
|
|
rule: id_or_var file_mode id_or_var
|
2006-04-11 21:52:54 +00:00
|
|
|
{
|
|
|
|
/* Oopsie, we appear to be missing an EOL marker. If we
|
|
|
|
* were *smart*, we could work around it. Since we're
|
|
|
|
* obviously not smart, we'll just punt with a more
|
|
|
|
* sensible error. */
|
|
|
|
yyerror(_("missing an end of line character? (entry: %s)"), $1);
|
|
|
|
};
|
|
|
|
|
2008-03-13 16:49:10 +00:00
|
|
|
rule: TOK_LINK opt_subset_flag TOK_ID TOK_ARROW TOK_ID TOK_END_OF_RULE
|
2007-11-16 09:37:31 +00:00
|
|
|
{
|
|
|
|
struct cod_entry *entry;
|
2008-03-13 16:49:10 +00:00
|
|
|
PDEBUG("Matched: link tok_id (%s) -> (%s)\n", $3, $5);
|
|
|
|
entry = new_entry(NULL, $3, AA_LINK_BITS, $5);
|
|
|
|
entry->subset = $2;
|
2007-11-16 09:37:31 +00:00
|
|
|
PDEBUG("rule.entry: link (%s)\n", entry->name);
|
|
|
|
$$ = entry;
|
|
|
|
};
|
|
|
|
|
2008-04-09 09:04:08 +00:00
|
|
|
rule: TOK_PTRACE TOK_ID TOK_END_OF_RULE
|
|
|
|
{
|
|
|
|
struct cod_entry *entry;
|
|
|
|
entry = new_entry(NULL, $2, AA_USER_PTRACE | AA_OTHER_PTRACE, NULL);
|
|
|
|
if (!entry)
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
$$ = entry;
|
|
|
|
};
|
|
|
|
|
|
|
|
rule: TOK_PTRACE TOK_COLON TOK_ID TOK_COLON TOK_ID TOK_END_OF_RULE
|
|
|
|
{
|
|
|
|
struct cod_entry *entry;
|
|
|
|
entry = new_entry($3, $5, AA_USER_PTRACE | AA_OTHER_PTRACE, NULL);
|
|
|
|
if (!entry)
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
$$ = entry;
|
|
|
|
};
|
|
|
|
|
2007-07-27 20:48:24 +00:00
|
|
|
hat: hat_start TOK_ID flags TOK_OPEN rules TOK_CLOSE
|
2006-04-11 21:52:54 +00:00
|
|
|
{
|
|
|
|
struct codomain *cod = $5;
|
|
|
|
PDEBUG("Matched: sep id (%s) open rules close\n", $2);
|
|
|
|
if (!cod) {
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
}
|
|
|
|
cod->name = $2;
|
|
|
|
cod->flags = $3;
|
2008-06-09 11:48:13 +00:00
|
|
|
cod->flags.hat = 1;
|
2006-04-11 21:52:54 +00:00
|
|
|
if (force_complain)
|
2009-03-12 19:19:35 +00:00
|
|
|
cod->flags.complain = 1;
|
2008-11-19 14:00:06 +00:00
|
|
|
post_process_nt_entries(cod);
|
2006-04-11 21:52:54 +00:00
|
|
|
PDEBUG("^%s: flags='%s%s'\n",
|
|
|
|
$2,
|
|
|
|
cod->flags.complain ? "complain, " : "",
|
|
|
|
cod->flags.audit ? "audit" : "");
|
|
|
|
$$ = cod;
|
|
|
|
};
|
|
|
|
|
2008-04-16 06:54:51 +00:00
|
|
|
/*
|
2008-04-16 04:45:02 +00:00
|
|
|
local_profile: opt_audit_flag opt_owner_flag TOK_ID file_mode TOK_ARROW TOK_OPEN rules TOK_CLOSE
|
|
|
|
{
|
|
|
|
int audit = 0, mode = $4;
|
|
|
|
if ($2 == 1)
|
|
|
|
mode &= (AA_USER_PERMS | AA_SHARED_PERMS | AA_USER_PTRACE);
|
|
|
|
else if ($2 == 2)
|
|
|
|
mode &= (AA_OTHER_PERMS | AA_SHARED_PERMS | AA_OTHER_PTRACE);
|
|
|
|
if ($1)
|
|
|
|
audit = mode & ~ALL_AA_EXEC_TYPE;
|
|
|
|
|
|
|
|
$$ = do_local_profile($7, $3, mode, audit);
|
|
|
|
};
|
|
|
|
|
|
|
|
local_profile: opt_audit_flag opt_owner_flag file_mode TOK_ID TOK_ARROW TOK_OPEN rules TOK_CLOSE
|
|
|
|
{
|
|
|
|
int audit = 0, mode = $3;
|
|
|
|
mode &= ~ALL_AA_EXEC_UNSAFE;
|
|
|
|
if ($2 == 1)
|
|
|
|
mode &= (AA_USER_PERMS | AA_SHARED_PERMS | AA_USER_PTRACE);
|
|
|
|
else if ($2 == 2)
|
|
|
|
mode &= (AA_OTHER_PERMS | AA_SHARED_PERMS | AA_OTHER_PTRACE);
|
|
|
|
if ($1)
|
|
|
|
audit = mode & ~ALL_AA_EXEC_TYPE;
|
|
|
|
|
|
|
|
$$ = do_local_profile($7, $4, mode, audit);
|
|
|
|
};
|
|
|
|
|
|
|
|
local_profile: opt_audit_flag opt_owner_flag TOK_UNSAFE file_mode TOK_ID TOK_ARROW TOK_OPEN rules TOK_CLOSE
|
|
|
|
{
|
|
|
|
int unsafe = (($4 & AA_EXEC_BITS) << 8) & ALL_AA_EXEC_UNSAFE;
|
|
|
|
int audit = 0, mode = ($4 & ~ALL_AA_EXEC_UNSAFE) | unsafe;
|
|
|
|
if ($2 == 1)
|
|
|
|
mode &= (AA_USER_PERMS | AA_SHARED_PERMS | AA_USER_PTRACE);
|
|
|
|
else if ($2 == 2)
|
|
|
|
mode &= (AA_OTHER_PERMS | AA_SHARED_PERMS | AA_OTHER_PTRACE);
|
|
|
|
if ($1)
|
|
|
|
audit = mode & ~ALL_AA_EXEC_TYPE;
|
|
|
|
|
|
|
|
$$ = do_local_profile($8, $5, mode, audit);
|
|
|
|
};
|
2008-04-16 06:54:51 +00:00
|
|
|
*/
|
2008-04-16 04:45:02 +00:00
|
|
|
|
|
|
|
local_profile: TOK_PROFILE TOK_ID flags TOK_OPEN rules TOK_CLOSE
|
|
|
|
{
|
|
|
|
struct codomain *cod = do_local_profile($5, $2, 0, 0);
|
|
|
|
cod->flags = $3;
|
|
|
|
$$ = cod;
|
|
|
|
};
|
|
|
|
|
2007-07-27 20:29:47 +00:00
|
|
|
network_rule: TOK_NETWORK TOK_END_OF_RULE
|
|
|
|
{
|
2009-07-24 17:24:41 +00:00
|
|
|
size_t family;
|
2007-07-27 20:29:47 +00:00
|
|
|
struct aa_network_entry *new_entry, *entry = NULL;
|
2009-07-24 17:24:41 +00:00
|
|
|
for (family = AF_UNSPEC; family < get_af_max(); family++) {
|
2007-07-27 20:29:47 +00:00
|
|
|
new_entry = new_network_ent(family, 0xffffffff,
|
|
|
|
0xffffffff);
|
|
|
|
if (!new_entry)
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
new_entry->next = entry;
|
|
|
|
entry = new_entry;
|
|
|
|
}
|
|
|
|
$$ = entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
network_rule: TOK_NETWORK TOK_ID TOK_END_OF_RULE
|
|
|
|
{
|
|
|
|
struct aa_network_entry *entry;
|
|
|
|
entry = network_entry($2, NULL, NULL);
|
|
|
|
if (!entry)
|
|
|
|
/* test for short circuiting of family */
|
|
|
|
entry = network_entry(NULL, $2, NULL);
|
|
|
|
if (!entry)
|
|
|
|
yyerror(_("Invalid network entry."));
|
|
|
|
free($2);
|
|
|
|
$$ = entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
network_rule: TOK_NETWORK TOK_ID TOK_ID TOK_END_OF_RULE
|
|
|
|
{
|
|
|
|
struct aa_network_entry *entry;
|
|
|
|
entry = network_entry($2, $3, NULL);
|
|
|
|
if (!entry)
|
|
|
|
yyerror(_("Invalid network entry."));
|
|
|
|
free($2);
|
|
|
|
free($3);
|
|
|
|
$$ = entry;
|
|
|
|
}
|
2006-04-11 21:52:54 +00:00
|
|
|
|
2007-07-27 20:48:24 +00:00
|
|
|
hat_start: TOK_SEP {}
|
|
|
|
| TOK_HAT {}
|
|
|
|
|
2007-07-27 20:47:17 +00:00
|
|
|
file_mode: TOK_MODE
|
|
|
|
{
|
2007-11-16 09:35:31 +00:00
|
|
|
/* A single TOK_MODE maps to the same permission in all
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
* of user::other */
|
2007-07-27 20:47:17 +00:00
|
|
|
$$ = parse_mode($1);
|
|
|
|
free($1);
|
|
|
|
}
|
2006-04-11 21:52:54 +00:00
|
|
|
|
2008-04-16 04:45:02 +00:00
|
|
|
change_profile: TOK_CHANGE_PROFILE TOK_ARROW TOK_ID TOK_END_OF_RULE
|
2007-06-26 21:10:28 +00:00
|
|
|
{
|
|
|
|
struct cod_entry *entry;
|
2008-04-16 04:45:02 +00:00
|
|
|
PDEBUG("Matched change_profile: tok_id (%s)\n", $3);
|
|
|
|
entry = new_entry(NULL, $3, AA_CHANGE_PROFILE, NULL);
|
2007-11-16 09:18:48 +00:00
|
|
|
if (!entry)
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
PDEBUG("change_profile.entry: (%s)\n", entry->name);
|
|
|
|
$$ = entry;
|
|
|
|
};
|
|
|
|
|
2008-04-16 04:45:02 +00:00
|
|
|
change_profile: TOK_CHANGE_PROFILE TOK_ARROW TOK_COLON TOK_ID TOK_COLON TOK_ID TOK_END_OF_RULE
|
2007-11-16 09:18:48 +00:00
|
|
|
{
|
|
|
|
struct cod_entry *entry;
|
2008-04-16 04:45:02 +00:00
|
|
|
PDEBUG("Matched change_profile: tok_id (%s:%s)\n", $4, $6);
|
|
|
|
entry = new_entry($4, $6, AA_CHANGE_PROFILE, NULL);
|
2007-06-26 21:10:28 +00:00
|
|
|
if (!entry)
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
PDEBUG("change_profile.entry: (%s)\n", entry->name);
|
|
|
|
$$ = entry;
|
|
|
|
};
|
|
|
|
|
2008-04-06 18:55:27 +00:00
|
|
|
|
|
|
|
set_caps: TOK_SET TOK_CAPABILITY caps TOK_END_OF_RULE
|
|
|
|
{
|
|
|
|
$$ = $3;
|
|
|
|
};
|
|
|
|
|
2007-11-16 09:32:38 +00:00
|
|
|
capability: TOK_CAPABILITY caps TOK_END_OF_RULE
|
2006-04-11 21:52:54 +00:00
|
|
|
{
|
Add Audit control to AppArmor through, the use of audit and deny
key words. Deny is also used to subtract permissions from the
profiles permission set.
the audit key word can be prepended to any file, network, or capability
rule, to force a selective audit when that rule is matched. Audit
permissions accumulate just like standard permissions.
eg.
audit /bin/foo rw,
will force an audit message when the file /bin/foo is opened for
read or write.
audit /etc/shadow w,
/etc/shadow r,
will force an audit message when /etc/shadow is opened for writing.
The audit message is per permission bit so only opening the file
for read access will not, force an audit message.
audit can also be used in block form instead of prepending audit
to every rule.
audit {
/bin/foo rw,
/etc/shadow w,
}
/etc/shadow r, # don't audit r access to /etc/shadow
the deny key word can be prepended to file, network and capability
rules, to result in a denial of permissions when matching that rule.
The deny rule specifically does 3 things
- it gives AppArmor the ability to remember what has been denied
so that the tools don't prompt for what has been denied in
previous profiling sessions.
- it subtracts globally from the allowed permissions. Deny permissions
accumulate in the the deny set just as allow permissions accumulate
then, the deny set is subtracted from the allow set.
- it quiets known rejects. The default audit behavior of deny rules
is to quiet known rejects so that audit logs are not flooded
with already known rejects. To have known rejects logged prepend
the audit keyword to the deny rule. Deny rules do not have a
block form.
eg.
deny /foo/bar rw,
audit deny /etc/shadow w,
audit {
deny owner /blah w,
deny other /foo w,
deny /etc/shadow w,
}
2008-03-13 17:39:03 +00:00
|
|
|
$$ = $2;
|
2006-04-11 21:52:54 +00:00
|
|
|
};
|
|
|
|
|
2007-11-16 09:32:38 +00:00
|
|
|
caps: caps TOK_ID
|
|
|
|
{
|
|
|
|
int cap = name_to_capability($2);
|
|
|
|
if (cap == -1)
|
|
|
|
yyerror(_("Invalid capability %s."), $2);
|
2009-08-20 15:27:12 +00:00
|
|
|
free($2);
|
2007-11-16 09:32:38 +00:00
|
|
|
$$ = $1 | CAP_TO_MASK(cap);
|
|
|
|
}
|
|
|
|
|
|
|
|
caps: TOK_ID
|
|
|
|
{
|
|
|
|
int cap = name_to_capability($1);
|
|
|
|
if (cap == -1)
|
|
|
|
yyerror(_("Invalid capability %s."), $1);
|
2009-08-20 15:27:12 +00:00
|
|
|
free($1);
|
2007-11-16 09:32:38 +00:00
|
|
|
$$ = CAP_TO_MASK(cap);
|
|
|
|
};
|
|
|
|
|
2006-04-11 21:52:54 +00:00
|
|
|
%%
|
|
|
|
#define MAXBUFSIZE 4096
|
|
|
|
|
|
|
|
void yyerror(char *msg, ...)
|
|
|
|
{
|
|
|
|
va_list arg;
|
|
|
|
char buf[MAXBUFSIZE];
|
|
|
|
|
|
|
|
va_start(arg, msg);
|
|
|
|
vsnprintf(buf, sizeof(buf), msg, arg);
|
|
|
|
va_end(arg);
|
|
|
|
|
|
|
|
if (profilename) {
|
2010-06-04 18:47:44 -07:00
|
|
|
PERROR(_("AppArmor parser error for %s%s%s at line %d: %s\n"),
|
|
|
|
profilename,
|
|
|
|
current_filename ? " in " : "",
|
|
|
|
current_filename ? current_filename : "",
|
|
|
|
current_lineno, buf);
|
2006-04-11 21:52:54 +00:00
|
|
|
} else {
|
2010-06-04 18:47:44 -07:00
|
|
|
PERROR(_("AppArmor parser error,%s%s line %d: %s\n"),
|
|
|
|
current_filename ? " in " : "",
|
|
|
|
current_filename ? current_filename : "",
|
2006-04-11 21:52:54 +00:00
|
|
|
current_lineno, buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
void free_value_list(struct value_list *list)
|
|
|
|
{
|
|
|
|
struct value_list *next;
|
|
|
|
|
|
|
|
while (list) {
|
|
|
|
next = list->next;
|
|
|
|
if (list->value)
|
|
|
|
free(list->value);
|
|
|
|
free(list);
|
|
|
|
list = next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-11-16 09:37:31 +00:00
|
|
|
struct cod_entry *do_file_rule(char *namespace, char *id, int mode,
|
2008-04-16 04:45:02 +00:00
|
|
|
char *link_id, char *nt)
|
2007-07-27 20:55:25 +00:00
|
|
|
{
|
|
|
|
struct cod_entry *entry;
|
|
|
|
PDEBUG("Matched: tok_id (%s) tok_mode (0x%x)\n", id, mode);
|
2007-11-16 09:37:31 +00:00
|
|
|
entry = new_entry(namespace, id, mode, link_id);
|
2007-07-27 20:55:25 +00:00
|
|
|
if (!entry)
|
|
|
|
yyerror(_("Memory allocation error."));
|
2008-04-16 04:45:02 +00:00
|
|
|
entry->nt_name = nt;
|
2007-07-27 20:55:25 +00:00
|
|
|
PDEBUG("rule.entry: (%s)\n", entry->name);
|
|
|
|
return entry;
|
|
|
|
}
|
2008-04-16 04:45:02 +00:00
|
|
|
|
2008-06-04 07:24:38 +00:00
|
|
|
/* Note: NOT currently in use, used for
|
|
|
|
* /foo x -> { /bah, } style transitions
|
|
|
|
*/
|
2008-04-16 04:45:02 +00:00
|
|
|
void add_local_entry(struct codomain *cod)
|
|
|
|
{
|
|
|
|
/* ugh this has to be called after the hat is attached to its parent */
|
|
|
|
if (cod->local_mode) {
|
|
|
|
struct cod_entry *entry;
|
|
|
|
char *trans = malloc(strlen(cod->parent->name) +
|
|
|
|
strlen(cod->name) + 3);
|
|
|
|
char *name = strdup(cod->name);
|
|
|
|
if (!trans)
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
sprintf(name, "%s//%s", cod->parent->name, cod->name);
|
|
|
|
|
|
|
|
entry = new_entry(NULL, name, cod->local_mode, NULL);
|
|
|
|
entry->audit = cod->local_audit;
|
|
|
|
entry->nt_name = trans;
|
|
|
|
if (!entry)
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
|
|
|
|
add_entry_to_policy(cod, entry);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
struct codomain *do_local_profile(struct codomain *cod, char *name, int mode,
|
|
|
|
int audit)
|
|
|
|
{
|
|
|
|
PDEBUG("Matched: local profile trans (%s) open rules close\n", $1);
|
|
|
|
if (!cod) {
|
|
|
|
yyerror(_("Memory allocation error."));
|
|
|
|
}
|
|
|
|
cod->name = name;
|
|
|
|
if (force_complain)
|
2009-03-12 19:19:35 +00:00
|
|
|
cod->flags.complain = 1;
|
2008-11-19 14:00:06 +00:00
|
|
|
post_process_nt_entries(cod);
|
2008-04-16 04:45:02 +00:00
|
|
|
PDEBUG("profile %s: flags='%s%s'\n",
|
|
|
|
name,
|
|
|
|
cod->flags.complain ? "complain, " : "",
|
|
|
|
cod->flags.audit ? "audit" : "");
|
|
|
|
|
|
|
|
cod->local = 1;
|
|
|
|
cod->local_mode = mode;
|
|
|
|
cod->local_audit = audit;
|
|
|
|
|
|
|
|
return cod;
|
|
|
|
}
|