Pathname matching, transition table loading, profile loading and
manipulation.
Signed-off-by: John Johansen <[email protected]>
Signed-off-by: Andreas Gruenbacher <[email protected]>
---
security/apparmor/match.c | 232 ++++++++++++
security/apparmor/match.h | 83 ++++
security/apparmor/module_interface.c | 643 +++++++++++++++++++++++++++++++++++
3 files changed, 958 insertions(+)
--- /dev/null
+++ b/security/apparmor/match.c
@@ -0,0 +1,232 @@
+/*
+ * Copyright (C) 2007 Novell/SUSE
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ * Regular expression transition table matching
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/errno.h>
+#include "match.h"
+
+static struct table_header *unpack_table(void *blob, size_t bsize)
+{
+ struct table_header *table = NULL;
+ struct table_header th;
+ size_t tsize;
+
+ if (bsize < sizeof(struct table_header))
+ goto out;
+
+ th.td_id = be16_to_cpu(*(u16 *) (blob));
+ th.td_flags = be16_to_cpu(*(u16 *) (blob + 2));
+ th.td_lolen = be32_to_cpu(*(u32 *) (blob + 8));
+ blob += sizeof(struct table_header);
+
+ if (!(th.td_flags == YYTD_DATA16 || th.td_flags == YYTD_DATA32 ||
+ th.td_flags == YYTD_DATA8))
+ goto out;
+
+ tsize = table_size(th.td_lolen, th.td_flags);
+ if (bsize < tsize)
+ goto out;
+
+ table = kmalloc(tsize, GFP_KERNEL);
+ if (table) {
+ *table = th;
+ if (th.td_flags == YYTD_DATA8)
+ UNPACK_ARRAY(table->td_data, blob, th.td_lolen,
+ u8, byte_to_byte);
+ else if (th.td_flags == YYTD_DATA16)
+ UNPACK_ARRAY(table->td_data, blob, th.td_lolen,
+ u16, be16_to_cpu);
+ else
+ UNPACK_ARRAY(table->td_data, blob, th.td_lolen,
+ u32, be32_to_cpu);
+ }
+
+out:
+ return table;
+}
+
+int unpack_dfa(struct aa_dfa *dfa, void *blob, size_t size)
+{
+ int hsize, i;
+ int error = -ENOMEM;
+
+ /* get dfa table set header */
+ if (size < sizeof(struct table_set_header))
+ goto fail;
+
+ if (ntohl(*(u32 *)blob) != YYTH_MAGIC)
+ goto fail;
+
+ hsize = ntohl(*(u32 *)(blob + 4));
+ if (size < hsize)
+ goto fail;
+
+ blob += hsize;
+ size -= hsize;
+
+ error = -EPROTO;
+ while (size > 0) {
+ struct table_header *table;
+ table = unpack_table(blob, size);
+ if (!table)
+ goto fail;
+
+ switch(table->td_id) {
+ case YYTD_ID_ACCEPT:
+ case YYTD_ID_BASE:
+ dfa->tables[table->td_id - 1] = table;
+ if (table->td_flags != YYTD_DATA32)
+ goto fail;
+ break;
+ case YYTD_ID_DEF:
+ case YYTD_ID_NXT:
+ case YYTD_ID_CHK:
+ dfa->tables[table->td_id - 1] = table;
+ if (table->td_flags != YYTD_DATA16)
+ goto fail;
+ break;
+ case YYTD_ID_EC:
+ dfa->tables[table->td_id - 1] = table;
+ if (table->td_flags != YYTD_DATA8)
+ goto fail;
+ break;
+ default:
+ kfree(table);
+ goto fail;
+ }
+
+ blob += table_size(table->td_lolen, table->td_flags);
+ size -= table_size(table->td_lolen, table->td_flags);
+ }
+
+ return 0;
+
+fail:
+ for (i = 0; i < ARRAY_SIZE(dfa->tables); i++) {
+ if (dfa->tables[i]) {
+ kfree(dfa->tables[i]);
+ dfa->tables[i] = NULL;
+ }
+ }
+ return error;
+}
+
+/**
+ * verify_dfa - verify that all the transitions and states in the dfa tables
+ * are in bounds.
+ * @dfa: dfa to test
+ *
+ * assumes dfa has gone through the verification done by unpacking
+ */
+int verify_dfa(struct aa_dfa *dfa)
+{
+ size_t i, state_count, trans_count;
+ int error = -EPROTO;
+
+ /* check that required tables exist */
+ if (!(dfa->tables[YYTD_ID_ACCEPT -1 ] &&
+ dfa->tables[YYTD_ID_DEF - 1] &&
+ dfa->tables[YYTD_ID_BASE - 1] &&
+ dfa->tables[YYTD_ID_NXT - 1] &&
+ dfa->tables[YYTD_ID_CHK - 1]))
+ goto out;
+
+ /* accept.size == default.size == base.size */
+ state_count = dfa->tables[YYTD_ID_BASE - 1]->td_lolen;
+ if (!(state_count == dfa->tables[YYTD_ID_DEF - 1]->td_lolen &&
+ state_count == dfa->tables[YYTD_ID_ACCEPT - 1]->td_lolen))
+ goto out;
+
+ /* next.size == chk.size */
+ trans_count = dfa->tables[YYTD_ID_NXT - 1]->td_lolen;
+ if (trans_count != dfa->tables[YYTD_ID_CHK - 1]->td_lolen)
+ goto out;
+
+ /* if equivalence classes then its table size must be 256 */
+ if (dfa->tables[YYTD_ID_EC - 1] &&
+ dfa->tables[YYTD_ID_EC - 1]->td_lolen != 256)
+ goto out;
+
+ for (i = 0; i < state_count; i++) {
+ if (DEFAULT_TABLE(dfa)[i] >= state_count)
+ goto out;
+ if (BASE_TABLE(dfa)[i] >= trans_count + 256)
+ goto out;
+ }
+
+ for (i = 0; i < trans_count ; i++) {
+ if (NEXT_TABLE(dfa)[i] >= state_count)
+ goto out;
+ if (CHECK_TABLE(dfa)[i] >= state_count)
+ goto out;
+ }
+
+ error = 0;
+out:
+ return error;
+}
+
+struct aa_dfa *aa_match_alloc(void)
+{
+ return kzalloc(sizeof(struct aa_dfa), GFP_KERNEL);
+}
+
+void aa_match_free(struct aa_dfa *dfa)
+{
+ if (dfa) {
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(dfa->tables); i++)
+ kfree(dfa->tables[i]);
+ }
+ kfree(dfa);
+}
+
+/**
+ * aa_dfa_match - match @path against @dfa starting in @state
+ * @dfa: the dfa to match @path against
+ * @state: the state to start matching in
+ * @path: the path to match against the dfa
+ *
+ * aa_dfa_match will match the full path length and return the state it
+ * finished matching in. The final state is used to look up the accepting
+ * label.
+ */
+unsigned int aa_dfa_match(struct aa_dfa *dfa, const char *str)
+{
+ u16 *def = DEFAULT_TABLE(dfa);
+ u32 *base = BASE_TABLE(dfa);
+ u16 *next = NEXT_TABLE(dfa);
+ u16 *check = CHECK_TABLE(dfa);
+ unsigned int state = 1, pos;
+
+ /* current state is <state>, matching character *str */
+ if (dfa->tables[YYTD_ID_EC - 1]) {
+ u8 *equiv = EQUIV_TABLE(dfa);
+ while (*str) {
+ pos = base[state] + equiv[(u8)*str++];
+ if (check[pos] == state)
+ state = next[pos];
+ else
+ state = def[state];
+ }
+ } else {
+ while (*str) {
+ pos = base[state] + (u8)*str++;
+ if (check[pos] == state)
+ state = next[pos];
+ else
+ state = def[state];
+ }
+ }
+ return ACCEPT_TABLE(dfa)[state];
+}
--- /dev/null
+++ b/security/apparmor/match.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (C) 2007 Novell/SUSE
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ * AppArmor submodule (match) prototypes
+ */
+
+#ifndef __MATCH_H
+#define __MATCH_H
+
+/**
+ * The format used for transition tables is based on the GNU flex table
+ * file format (--tables-file option; see Table File Format in the flex
+ * info pages and the flex sources for documentation). The magic number
+ * used in the header is 0x1B5E783D insted of 0xF13C57B1 though, because
+ * the YY_ID_CHK (check) and YY_ID_DEF (default) tables are used
+ * slightly differently (see the apparmor-parser package).
+ */
+
+#define YYTH_MAGIC 0x1B5E783D
+
+struct table_set_header {
+ u32 th_magic; /* YYTH_MAGIC */
+ u32 th_hsize;
+ u32 th_ssize;
+ u16 th_flags;
+ char th_version[];
+};
+
+#define YYTD_ID_ACCEPT 1
+#define YYTD_ID_BASE 2
+#define YYTD_ID_CHK 3
+#define YYTD_ID_DEF 4
+#define YYTD_ID_EC 5
+#define YYTD_ID_META 6
+#define YYTD_ID_NXT 8
+
+
+#define YYTD_DATA8 1
+#define YYTD_DATA16 2
+#define YYTD_DATA32 4
+
+struct table_header {
+ u16 td_id;
+ u16 td_flags;
+ u32 td_hilen;
+ u32 td_lolen;
+ char td_data[];
+};
+
+#define DEFAULT_TABLE(DFA) ((u16 *)((DFA)->tables[YYTD_ID_DEF - 1]->td_data))
+#define BASE_TABLE(DFA) ((u32 *)((DFA)->tables[YYTD_ID_BASE - 1]->td_data))
+#define NEXT_TABLE(DFA) ((u16 *)((DFA)->tables[YYTD_ID_NXT - 1]->td_data))
+#define CHECK_TABLE(DFA) ((u16 *)((DFA)->tables[YYTD_ID_CHK - 1]->td_data))
+#define EQUIV_TABLE(DFA) ((u8 *)((DFA)->tables[YYTD_ID_EC - 1]->td_data))
+#define ACCEPT_TABLE(DFA) ((u32 *)((DFA)->tables[YYTD_ID_ACCEPT - 1]->td_data))
+
+struct aa_dfa {
+ struct table_header *tables[YYTD_ID_NXT];
+};
+
+#define byte_to_byte(X) (X)
+
+#define UNPACK_ARRAY(TABLE, BLOB, LEN, TYPE, NTOHX) \
+ do { \
+ typeof(LEN) __i; \
+ TYPE *__t = (TYPE *) TABLE; \
+ TYPE *__b = (TYPE *) BLOB; \
+ for (__i = 0; __i < LEN; __i++) { \
+ __t[__i] = NTOHX(__b[__i]); \
+ } \
+ } while (0)
+
+static inline size_t table_size(size_t len, size_t el_size)
+{
+ return ALIGN(sizeof(struct table_header) + len * el_size, 8);
+}
+
+#endif /* __MATCH_H */
--- /dev/null
+++ b/security/apparmor/module_interface.c
@@ -0,0 +1,643 @@
+/*
+ * Copyright (C) 1998-2007 Novell/SUSE
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ * AppArmor userspace policy interface
+ */
+
+#include <asm/unaligned.h>
+
+#include "apparmor.h"
+#include "inline.h"
+
+/*
+ * This mutex is used to synchronize profile adds, replacements, and
+ * removals: we only allow one of these operations at a time.
+ * We do not use the profile list lock here in order to avoid blocking
+ * exec during those operations. (Exec involves a profile list lookup
+ * for named-profile transitions.)
+ */
+DEFINE_MUTEX(aa_interface_lock);
+
+/*
+ * The AppArmor interface treats data as a type byte followed by the
+ * actual data. The interface has the notion of a a named entry
+ * which has a name (AA_NAME typecode followed by name string) followed by
+ * the entries typecode and data. Named types allow for optional
+ * elements and extensions to be added and tested for without breaking
+ * backwards compatability.
+ */
+
+enum aa_code {
+ AA_U8,
+ AA_U16,
+ AA_U32,
+ AA_U64,
+ AA_NAME, /* same as string except it is items name */
+ AA_STRING,
+ AA_BLOB,
+ AA_STRUCT,
+ AA_STRUCTEND,
+ AA_LIST,
+ AA_LISTEND,
+};
+
+/*
+ * aa_ext is the read of the buffer containing the serialized profile. The
+ * data is copied into a kernel buffer in apparmorfs and then handed off to
+ * the unpack routines.
+ */
+struct aa_ext {
+ void *start;
+ void *end;
+ void *pos; /* pointer to current position in the buffer */
+ u32 version;
+};
+
+static inline int aa_inbounds(struct aa_ext *e, size_t size)
+{
+ return (size <= e->end - e->pos);
+}
+
+/**
+ * aa_u16_chunck - test and do bounds checking for a u16 size based chunk
+ * @e: serialized data read head
+ * @chunk: start address for chunk of data
+ *
+ * return the size of chunk found with the read head at the end of
+ * the chunk.
+ */
+static size_t aa_is_u16_chunk(struct aa_ext *e, char **chunk)
+{
+ void *pos = e->pos;
+ size_t size = 0;
+
+ if (!aa_inbounds(e, sizeof(u16)))
+ goto fail;
+ size = le16_to_cpu(get_unaligned((u16 *)e->pos));
+ e->pos += sizeof(u16);
+ if (!aa_inbounds(e, size))
+ goto fail;
+ *chunk = e->pos;
+ e->pos += size;
+ return size;
+
+fail:
+ e->pos = pos;
+ return 0;
+}
+
+static inline int aa_is_X(struct aa_ext *e, enum aa_code code)
+{
+ if (!aa_inbounds(e, 1))
+ return 0;
+ if (*(u8 *) e->pos != code)
+ return 0;
+ e->pos++;
+ return 1;
+}
+
+/**
+ * aa_is_nameX - check is the next element is of type X with a name of @name
+ * @e: serialized data extent information
+ * @code: type code
+ * @name: name to match to the serialized element.
+ *
+ * check that the next serialized data element is of type X and has a tag
+ * name @name. If @name is specified then there must be a matching
+ * name element in the stream. If @name is NULL any name element will be
+ * skipped and only the typecode will be tested.
+ * returns 1 on success (both type code and name tests match) and the read
+ * head is advanced past the headers
+ * returns %0 if either match failes, the read head does not move
+ */
+static int aa_is_nameX(struct aa_ext *e, enum aa_code code, const char *name)
+{
+ void *pos = e->pos;
+ /*
+ * Check for presence of a tagname, and if present name size
+ * AA_NAME tag value is a u16.
+ */
+ if (aa_is_X(e, AA_NAME)) {
+ char *tag;
+ size_t size = aa_is_u16_chunk(e, &tag);
+ /* if a name is specified it must match. otherwise skip tag */
+ if (name && (!size || strcmp(name, tag)))
+ goto fail;
+ } else if (name) {
+ /* if a name is specified and there is no name tag fail */
+ goto fail;
+ }
+
+ /* now check if type code matches */
+ if (aa_is_X(e, code))
+ return 1;
+
+fail:
+ e->pos = pos;
+ return 0;
+}
+
+static int aa_is_u32(struct aa_ext *e, u32 *data, const char *name)
+{
+ void *pos = e->pos;
+ if (aa_is_nameX(e, AA_U32, name)) {
+ if (!aa_inbounds(e, sizeof(u32)))
+ goto fail;
+ if (data)
+ *data = le32_to_cpu(get_unaligned((u32 *)e->pos));
+ e->pos += sizeof(u32);
+ return 1;
+ }
+fail:
+ e->pos = pos;
+ return 0;
+}
+
+static size_t aa_is_blob(struct aa_ext *e, char **blob, const char *name)
+{
+ void *pos = e->pos;
+ if (aa_is_nameX(e, AA_BLOB, name)) {
+ u32 size;
+ if (!aa_inbounds(e, sizeof(u32)))
+ goto fail;
+ size = le32_to_cpu(get_unaligned((u32 *)e->pos));
+ e->pos += sizeof(u32);
+ if (aa_inbounds(e, (size_t) size)) {
+ * blob = e->pos;
+ e->pos += size;
+ return size;
+ }
+ }
+fail:
+ e->pos = pos;
+ return 0;
+}
+
+static int aa_is_dynstring(struct aa_ext *e, char **string, const char *name)
+{
+ char *src_str;
+ size_t size = 0;
+ void *pos = e->pos;
+ *string = NULL;
+ if (aa_is_nameX(e, AA_STRING, name) &&
+ (size = aa_is_u16_chunk(e, &src_str))) {
+ char *str;
+ if (!(str = kmalloc(size, GFP_KERNEL)))
+ goto fail;
+ memcpy(str, src_str, size);
+ *string = str;
+ }
+
+ return size;
+
+fail:
+ e->pos = pos;
+ return 0;
+}
+
+/**
+ * aa_unpack_dfa - unpack a file rule dfa
+ * @e: serialized data extent information
+ *
+ * returns dfa or ERR_PTR
+ */
+struct aa_dfa *aa_unpack_dfa(struct aa_ext *e)
+{
+ char *blob = NULL;
+ size_t size, error = 0;
+ struct aa_dfa *dfa = NULL;
+
+ size = aa_is_blob(e, &blob, "aadfa");
+ if (size) {
+ dfa = aa_match_alloc();
+ if (dfa) {
+ /*
+ * The dfa is aligned with in the blob to 8 bytes
+ * from the beginning of the stream.
+ */
+ size_t sz = blob - (char *) e->start;
+ size_t pad = ALIGN(sz, 8) - sz;
+ error = unpack_dfa(dfa, blob + pad, size - pad);
+ if (!error)
+ error = verify_dfa(dfa);
+ } else {
+ error = -ENOMEM;
+ }
+
+ if (error) {
+ aa_match_free(dfa);
+ dfa = ERR_PTR(error);
+ }
+ }
+
+ return dfa;
+}
+
+/**
+ * aa_unpack_profile - unpack a serialized profile
+ * @e: serialized data extent information
+ * @error: error code returned if unpacking fails
+ */
+static struct aa_profile *aa_unpack_profile(struct aa_ext *e, int depth)
+{
+ struct aa_profile *profile = NULL;
+
+ int error = -EPROTO;
+
+ profile = alloc_aa_profile();
+ if (!profile)
+ return ERR_PTR(-ENOMEM);
+
+ /* check that we have the right struct being passed */
+ if (!aa_is_nameX(e, AA_STRUCT, "profile"))
+ goto fail;
+ if (!aa_is_dynstring(e, &profile->name, NULL))
+ goto fail;
+
+ /* per profile debug flags (complain, audit) */
+ if (!aa_is_nameX(e, AA_STRUCT, "flags"))
+ goto fail;
+ if (!aa_is_u32(e, NULL, NULL))
+ goto fail;
+ if (!aa_is_u32(e, &(profile->flags.complain), NULL))
+ goto fail;
+ if (!aa_is_u32(e, &(profile->flags.audit), NULL))
+ goto fail;
+ if (!aa_is_nameX(e, AA_STRUCTEND, NULL))
+ goto fail;
+
+ if (!aa_is_u32(e, &(profile->capabilities), NULL))
+ goto fail;
+
+ /* get file rules */
+ profile->file_rules = aa_unpack_dfa(e);
+ if (IS_ERR(profile->file_rules)) {
+ error = PTR_ERR(profile->file_rules);
+ profile->file_rules = NULL;
+ goto fail;
+ }
+
+ /* get optional subprofiles */
+ if (aa_is_nameX(e, AA_LIST, "hats")) {
+ if (depth > 0)
+ goto fail;
+ while (!aa_is_nameX(e, AA_LISTEND, NULL)) {
+ struct aa_profile *subprofile;
+ subprofile = aa_unpack_profile(e, depth + 1);
+ if (IS_ERR(subprofile)) {
+ error = PTR_ERR(subprofile);
+ goto fail;
+ }
+ subprofile->parent = profile;
+ list_add(&subprofile->list, &profile->sub);
+ }
+ }
+
+ if (!aa_is_nameX(e, AA_STRUCTEND, NULL))
+ goto fail;
+
+ return profile;
+
+fail:
+ aa_audit_message(NULL, GFP_KERNEL, "Invalid profile %s",
+ profile && profile->name ? profile->name : "unknown");
+
+ if (profile)
+ free_aa_profile(profile);
+
+ return ERR_PTR(error);
+}
+
+/**
+ * aa_unpack_profile_wrapper - unpack a serialized base profile
+ * @e: serialized data extent information
+ *
+ * check interface version unpack a profile and all its hats and patch
+ * in any extra information that the profile needs.
+ */
+static struct aa_profile *aa_unpack_profile_wrapper(struct aa_ext *e)
+{
+ struct aa_profile *profile = aa_unpack_profile(e, 0);
+ if (!IS_ERR(profile) &&
+ (!list_empty(&profile->sub) || profile->flags.complain)) {
+ int error;
+ if ((error = attach_nullprofile(profile))) {
+ aa_put_profile(profile);
+ return ERR_PTR(error);
+ }
+ }
+
+ return profile;
+}
+
+/**
+ * aa_verify_head - unpack serialized stream header
+ * @e: serialized data read head
+ *
+ * returns error or 0 if header is good
+ */
+static int aa_verify_header(struct aa_ext *e)
+{
+ /* get the interface version */
+ if (!aa_is_u32(e, &e->version, "version")) {
+ aa_audit_message(NULL, GFP_KERNEL, "Interface version missing");
+ return -EPROTONOSUPPORT;
+ }
+
+ /* check that the interface version is currently supported */
+ if (e->version != 3) {
+ aa_audit_message(NULL, GFP_KERNEL, "Unsupported interface "
+ "version (%d)", e->version);
+ return -EPROTONOSUPPORT;
+ }
+ return 0;
+}
+
+/**
+ * aa_add_profile - Unpack and add a new profile to the profile list
+ * @data: serialized data stream
+ * @size: size of the serialized data stream
+ */
+ssize_t aa_add_profile(void *data, size_t size)
+{
+ struct aa_profile *profile = NULL;
+ struct aa_ext e = {
+ .start = data,
+ .end = data + size,
+ .pos = data
+ };
+ ssize_t error = aa_verify_header(&e);
+ if (error)
+ return error;
+
+ profile = aa_unpack_profile_wrapper(&e);
+ if (IS_ERR(profile))
+ return PTR_ERR(profile);
+
+ mutex_lock(&aa_interface_lock);
+ write_lock(&profile_list_lock);
+ if (__aa_find_profile(profile->name, &profile_list)) {
+ /* A profile with this name exists already. */
+ write_unlock(&profile_list_lock);
+ mutex_unlock(&aa_interface_lock);
+ aa_put_profile(profile);
+ return -EEXIST;
+ }
+ list_add(&profile->list, &profile_list);
+ write_unlock(&profile_list_lock);
+ mutex_unlock(&aa_interface_lock);
+
+ return size;
+}
+
+/**
+ * task_replace - replace a task's profile
+ * @task: task to replace profile on
+ * @new_cxt: new aa_task_context to do replacement with
+ * @new_profile: new profile
+ */
+static inline void task_replace(struct task_struct *task,
+ struct aa_task_context *new_cxt,
+ struct aa_profile *new_profile)
+{
+ struct aa_task_context *cxt = aa_task_context(task);
+
+ AA_DEBUG("%s: replacing profile for task %d "
+ "profile=%s (%p) hat=%s (%p)\n",
+ __FUNCTION__,
+ cxt->task->pid,
+ cxt->profile->parent->name, cxt->profile->parent,
+ cxt->profile->name, cxt->profile);
+
+ if (cxt->profile != cxt->profile->parent) {
+ struct aa_profile *hat;
+
+ /*
+ * The old profile was in a hat, check to see if the new
+ * profile has an equivalent hat.
+ */
+ hat = __aa_find_profile(cxt->profile->name, &new_profile->sub);
+
+ if (!hat)
+ hat = aa_dup_profile(new_profile->null_profile);
+
+ aa_change_task_context(task, new_cxt, hat, cxt->hat_magic);
+ aa_put_profile(hat);
+ } else
+ aa_change_task_context(task, new_cxt, new_profile,
+ cxt->hat_magic);
+}
+
+/**
+ * aa_replace_profile - replace a profile on the profile list
+ * @udata: serialized data stream
+ * @size: size of the serialized data stream
+ *
+ * unpack and replace a profile on the profile list and uses of that profile
+ * by any aa_task_context. If the profile does not exist on the profile list
+ * it is added. Return %0 or error.
+ */
+ssize_t aa_replace_profile(void *udata, size_t size)
+{
+ struct aa_profile *old_profile, *new_profile;
+ struct aa_task_context *new_cxt;
+ struct aa_ext e = {
+ .start = udata,
+ .end = udata + size,
+ .pos = udata
+ };
+ ssize_t error = aa_verify_header(&e);
+ if (error)
+ return error;
+
+ new_profile = aa_unpack_profile_wrapper(&e);
+ if (IS_ERR(new_profile))
+ return PTR_ERR(new_profile);
+
+ mutex_lock(&aa_interface_lock);
+ write_lock(&profile_list_lock);
+ old_profile = __aa_find_profile(new_profile->name, &profile_list);
+ if (old_profile) {
+ lock_profile(old_profile);
+ old_profile->isstale = 1;
+ unlock_profile(old_profile);
+ list_del_init(&old_profile->list);
+ }
+ list_add(&new_profile->list, &profile_list);
+ write_unlock(&profile_list_lock);
+
+ if (!old_profile)
+ goto out;
+
+ /*
+ * Replacement needs to allocate a new aa_task_context for each
+ * task confined by old_profile. To do this the profile locks
+ * are only held when the actual switch is done per task. While
+ * looping to allocate a new aa_task_context the old_task list
+ * may get shorter if tasks exit/change their profile but will
+ * not get longer as new task will not use old_profile detecting
+ * that is stale.
+ */
+ do {
+ new_cxt = aa_alloc_task_context(GFP_KERNEL | __GFP_NOFAIL);
+
+ lock_both_profiles(old_profile, new_profile);
+ if (!list_empty(&old_profile->task_contexts)) {
+ struct task_struct *task =
+ list_entry(old_profile->task_contexts.next,
+ struct aa_task_context, list)->task;
+ task_lock(task);
+ task_replace(task, new_cxt, new_profile);
+ task_unlock(task);
+ new_cxt = NULL;
+ }
+ unlock_both_profiles(old_profile, new_profile);
+ } while (!new_cxt);
+ aa_free_task_context(new_cxt);
+ aa_put_profile(old_profile);
+
+out:
+ mutex_unlock(&aa_interface_lock);
+ return size;
+}
+
+/**
+ * aa_remove_profile - remove a profile from the system
+ * @name: name of the profile to remove
+ * @size: size of the name
+ *
+ * remove a profile from the profile list and all aa_task_context references
+ * to said profile.
+ */
+ssize_t aa_remove_profile(const char *name, size_t size)
+{
+ struct aa_profile *profile;
+
+ mutex_lock(&aa_interface_lock);
+ write_lock(&profile_list_lock);
+ profile = __aa_find_profile(name, &profile_list);
+ if (!profile) {
+ write_unlock(&profile_list_lock);
+ mutex_unlock(&aa_interface_lock);
+ return -ENOENT;
+ }
+
+ /* Remove the profile from each task context it is on. */
+ lock_profile(profile);
+ profile->isstale = 1;
+ aa_unconfine_tasks(profile);
+ unlock_profile(profile);
+
+ /* Release the profile itself. */
+ list_del_init(&profile->list);
+ aa_put_profile(profile);
+ write_unlock(&profile_list_lock);
+ mutex_unlock(&aa_interface_lock);
+
+ return size;
+}
+
+/**
+ * free_aa_profile_kref - free aa_profile by kref (called by aa_put_profile)
+ * @kr: kref callback for freeing of a profile
+ */
+void free_aa_profile_kref(struct kref *kref)
+{
+ struct aa_profile *p=container_of(kref, struct aa_profile, count);
+
+ free_aa_profile(p);
+}
+
+/**
+ * alloc_aa_profile - allocate, initialize and return a new profile
+ * Returns NULL on failure.
+ */
+struct aa_profile *alloc_aa_profile(void)
+{
+ struct aa_profile *profile;
+
+ profile = kzalloc(sizeof(*profile), GFP_KERNEL);
+ AA_DEBUG("%s(%p)\n", __FUNCTION__, profile);
+ if (profile) {
+ profile->parent = profile;
+ INIT_LIST_HEAD(&profile->list);
+ INIT_LIST_HEAD(&profile->sub);
+ kref_init(&profile->count);
+ INIT_LIST_HEAD(&profile->task_contexts);
+ spin_lock_init(&profile->lock);
+ }
+ return profile;
+}
+
+/**
+ * free_aa_profile - free a profile
+ * @profile: the profile to free
+ *
+ * Free a profile, its hats and null_profile. All references to the profile,
+ * its hats and null_profile must have been put.
+ *
+ * If the profile was referenced from a task context, free_aa_profile() will
+ * be called from an rcu callback routine, so we must not sleep here.
+ */
+void free_aa_profile(struct aa_profile *profile)
+{
+ struct aa_profile *p, *ptmp;
+
+ AA_DEBUG("%s(%p)\n", __FUNCTION__, profile);
+
+ if (!profile)
+ return;
+
+ /* profile is still on global profile list -- invalid */
+ if (!list_empty(&profile->list)) {
+ AA_ERROR("%s: internal error, "
+ "profile '%s' still on global list\n",
+ __FUNCTION__,
+ profile->name);
+ BUG();
+ }
+
+ aa_match_free(profile->file_rules);
+
+ /*
+ * Use free_aa_profile instead of aa_put_profile to destroy the
+ * null_profile, because the null_profile use the same reference
+ * counting as hats, ie. the count goes to the base profile.
+ */
+ free_aa_profile(profile->null_profile);
+ list_for_each_entry_safe(p, ptmp, &profile->sub, list) {
+ list_del_init(&p->list);
+ p->parent = p;
+ aa_put_profile(p);
+ }
+
+ if (profile->name) {
+ AA_DEBUG("%s: %s\n", __FUNCTION__, profile->name);
+ kfree(profile->name);
+ }
+
+ kfree(profile);
+}
+
+/**
+ * aa_unconfine_tasks - remove tasks on a profile's task context list
+ * @profile: profile to remove tasks from
+ *
+ * Assumes that @profile lock is held.
+ */
+void aa_unconfine_tasks(struct aa_profile *profile)
+{
+ while (!list_empty(&profile->task_contexts)) {
+ struct task_struct *task =
+ list_entry(profile->task_contexts.next,
+ struct aa_task_context, list)->task;
+ task_lock(task);
+ aa_change_task_context(task, NULL, NULL, 0);
+ task_unlock(task);
+ }
+}
--
Hi!
> Pathname matching, transition table loading, profile loading and
> manipulation.
So we get small interpretter of state machines, and reason we need is
is 'apparmor is misdesigned and works with paths when it should have
worked with handles'.
If you solve the 'new file problem', aa becomes subset of selinux..
And I'm pretty sure patch will be nicer than this.
Pavel
> +int unpack_dfa(struct aa_dfa *dfa, void *blob, size_t size)
> +{
> + int hsize, i;
> + int error = -ENOMEM;
> +
> + /* get dfa table set header */
> + if (size < sizeof(struct table_set_header))
> + goto fail;
> +
> + if (ntohl(*(u32 *)blob) != YYTH_MAGIC)
> + goto fail;
> +
> + hsize = ntohl(*(u32 *)(blob + 4));
> + if (size < hsize)
> + goto fail;
> +
> + blob += hsize;
> + size -= hsize;
> +
> + error = -EPROTO;
> + while (size > 0) {
> + struct table_header *table;
> + table = unpack_table(blob, size);
> + if (!table)
> + goto fail;
> +
> + switch(table->td_id) {
> + case YYTD_ID_ACCEPT:
> + case YYTD_ID_BASE:
> + dfa->tables[table->td_id - 1] = table;
> + if (table->td_flags != YYTD_DATA32)
> + goto fail;
> + break;
> + case YYTD_ID_DEF:
> + case YYTD_ID_NXT:
> + case YYTD_ID_CHK:
> + dfa->tables[table->td_id - 1] = table;
> + if (table->td_flags != YYTD_DATA16)
> + goto fail;
> + break;
> + case YYTD_ID_EC:
> + dfa->tables[table->td_id - 1] = table;
> + if (table->td_flags != YYTD_DATA8)
> + goto fail;
> + break;
> + default:
> + kfree(table);
> + goto fail;
> + }
> +
> + blob += table_size(table->td_lolen, table->td_flags);
> + size -= table_size(table->td_lolen, table->td_flags);
> + }
> +
> + return 0;
> +
> +fail:
> + for (i = 0; i < ARRAY_SIZE(dfa->tables); i++) {
> + if (dfa->tables[i]) {
> + kfree(dfa->tables[i]);
> + dfa->tables[i] = NULL;
> + }
> + }
> + return error;
> +}
> +
> +/**
> + * verify_dfa - verify that all the transitions and states in the dfa tables
> + * are in bounds.
> + * @dfa: dfa to test
> + *
> + * assumes dfa has gone through the verification done by unpacking
> + */
> +int verify_dfa(struct aa_dfa *dfa)
> +{
> + size_t i, state_count, trans_count;
> + int error = -EPROTO;
> +
> + /* check that required tables exist */
> + if (!(dfa->tables[YYTD_ID_ACCEPT -1 ] &&
> + dfa->tables[YYTD_ID_DEF - 1] &&
> + dfa->tables[YYTD_ID_BASE - 1] &&
> + dfa->tables[YYTD_ID_NXT - 1] &&
> + dfa->tables[YYTD_ID_CHK - 1]))
> + goto out;
> +
> + /* accept.size == default.size == base.size */
> + state_count = dfa->tables[YYTD_ID_BASE - 1]->td_lolen;
> + if (!(state_count == dfa->tables[YYTD_ID_DEF - 1]->td_lolen &&
> + state_count == dfa->tables[YYTD_ID_ACCEPT - 1]->td_lolen))
> + goto out;
> +
> + /* next.size == chk.size */
> + trans_count = dfa->tables[YYTD_ID_NXT - 1]->td_lolen;
> + if (trans_count != dfa->tables[YYTD_ID_CHK - 1]->td_lolen)
> + goto out;
> +
> + /* if equivalence classes then its table size must be 256 */
> + if (dfa->tables[YYTD_ID_EC - 1] &&
> + dfa->tables[YYTD_ID_EC - 1]->td_lolen != 256)
> + goto out;
> +
> + for (i = 0; i < state_count; i++) {
> + if (DEFAULT_TABLE(dfa)[i] >= state_count)
> + goto out;
> + if (BASE_TABLE(dfa)[i] >= trans_count + 256)
> + goto out;
> + }
> +
> + for (i = 0; i < trans_count ; i++) {
> + if (NEXT_TABLE(dfa)[i] >= state_count)
> + goto out;
> + if (CHECK_TABLE(dfa)[i] >= state_count)
> + goto out;
> + }
> +
> + error = 0;
> +out:
> + return error;
> +}
> +
> +struct aa_dfa *aa_match_alloc(void)
> +{
> + return kzalloc(sizeof(struct aa_dfa), GFP_KERNEL);
> +}
> +
> +void aa_match_free(struct aa_dfa *dfa)
> +{
> + if (dfa) {
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(dfa->tables); i++)
> + kfree(dfa->tables[i]);
> + }
> + kfree(dfa);
> +}
> +
> +/**
> + * aa_dfa_match - match @path against @dfa starting in @state
> + * @dfa: the dfa to match @path against
> + * @state: the state to start matching in
> + * @path: the path to match against the dfa
> + *
> + * aa_dfa_match will match the full path length and return the state it
> + * finished matching in. The final state is used to look up the accepting
> + * label.
> + */
> +unsigned int aa_dfa_match(struct aa_dfa *dfa, const char *str)
> +{
> + u16 *def = DEFAULT_TABLE(dfa);
> + u32 *base = BASE_TABLE(dfa);
> + u16 *next = NEXT_TABLE(dfa);
> + u16 *check = CHECK_TABLE(dfa);
> + unsigned int state = 1, pos;
> +
> + /* current state is <state>, matching character *str */
> + if (dfa->tables[YYTD_ID_EC - 1]) {
> + u8 *equiv = EQUIV_TABLE(dfa);
> + while (*str) {
> + pos = base[state] + equiv[(u8)*str++];
> + if (check[pos] == state)
> + state = next[pos];
> + else
> + state = def[state];
> + }
> + } else {
> + while (*str) {
> + pos = base[state] + (u8)*str++;
> + if (check[pos] == state)
> + state = next[pos];
> + else
> + state = def[state];
> + }
> + }
> + return ACCEPT_TABLE(dfa)[state];
> +}
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tuesday 15 May 2007 11:20, Pavel Machek wrote:
> Hi!
>
> > Pathname matching, transition table loading, profile loading and
> > manipulation.
>
> So we get small interpretter of state machines, and reason we need is
> is 'apparmor is misdesigned and works with paths when it should have
> worked with handles'.
I assume you mean labels instead of handles.
AppArmor's design is around paths not labels, and independent of whether or
not you like AppArmor, this design leads to a useful security model distinct
from the SELinux security model (which is useful in its own ways). The
differences between those models cannot be argued away, neither is a subset
of the other, and neither is a misdesign. I would be thankful if you could
stop spreading this lie.
> If you solve the 'new file problem', aa becomes subset of selinux.
> And I'm pretty sure patch will be nicer than this.
You are quite mistaken. SELinux turns pathnames into labels when it initially
labels all files (when a policy is rolled out), whereas AppArmor computes
the "label" of each file when a file is opened. The two models start to
diverge as soon as files are renamed: in SELinux, labels stick with the
files. In AppArmor, "labels" stick with the names.
So what you advocate for is a hybrid between the SELinux and the AppArmor
model, not a superset.
It could be that the SELinux folks will solve the issues they are having with
new files using something better than restorecond in the future, perhaps even
an in-kernel mechanism (although I somewhat doubt it). But then again, their
basic model makes sense even without any live file relabeling, and so that's
probably not very high up on the priority list.
Andreas
On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote:
> On Tuesday 15 May 2007 11:20, Pavel Machek wrote:
> > Hi!
> >
> > > Pathname matching, transition table loading, profile loading and
> > > manipulation.
> >
> > So we get small interpretter of state machines, and reason we need is
> > is 'apparmor is misdesigned and works with paths when it should have
> > worked with handles'.
>
> I assume you mean labels instead of handles.
>
> AppArmor's design is around paths not labels, and independent of whether or
> not you like AppArmor, this design leads to a useful security model distinct
> from the SELinux security model (which is useful in its own ways). The
> differences between those models cannot be argued away, neither is a subset
> of the other, and neither is a misdesign. I would be thankful if you could
> stop spreading this lie.
I have a hard time distinguishing AppArmor's "model" from its
implementation; every time we suggest that one might emulate much of
AppArmor's functionality on SELinux (as in SEEdit), someone points to a
specific characteristic of the AppArmor implementation that cannot be
emulated in this manner. But is that implementation characteristic an
actual requirement or just how it happens to have been done to date in
AA? And I get the impression that even if we extended SELinux in
certain ways to ease such emulation, the AA folks would never be
satisfied because the implementation would still differ. Can we
separate the desired functionality and actual requirements from the
implementation specifics?
> > If you solve the 'new file problem', aa becomes subset of selinux.
> > And I'm pretty sure patch will be nicer than this.
>
> You are quite mistaken. SELinux turns pathnames into labels when it initially
> labels all files (when a policy is rolled out), whereas AppArmor computes
> the "label" of each file when a file is opened. The two models start to
> diverge as soon as files are renamed: in SELinux, labels stick with the
> files. In AppArmor, "labels" stick with the names.
I'd argue a bit with that characterization, given that:
- in the case of SELinux, the pathname is never used as a basis for
decisions by the kernel,
- under AA, each file may have an arbitrary set of "labels" or
"policies" applied to it depending on what programs are accessing it and
what names are being used to reference it - there is no system view of
the subjects and objects and thus no way to identify the overall system
policy for a given file.
- names are far less tranquil than labels.
> So what you advocate for is a hybrid between the SELinux and the AppArmor
> model, not a superset.
>
> It could be that the SELinux folks will solve the issues they are having with
> new files using something better than restorecond in the future, perhaps even
> an in-kernel mechanism (although I somewhat doubt it). But then again, their
> basic model makes sense even without any live file relabeling, and so that's
> probably not very high up on the priority list.
Live file relabeling (non-tranquility) tends to break one's ability to
show anything about preservation of confidentiality or integrity
(particularly in the absence of complete revocation support).
On the new files issue, it wouldn't be difficult or even a real
divergence from our existing model to introduce the component name (not
a "full" pathname, but the last component) as an additional input to the
decision for labeling new files (along with the existing use of the
creating process' label, the parent directory label, and the kind of new
file) at creation time, and that would reduce the need somewhat to
modify some applications that create files of multiple security contexts
in the same directory. That would further help the SEEdit folks in
emulating AA on top of SELinux, but as before, I don't get the
impression that the AA folks will ever be satisfied with such an
emulation, not because of any real requirement but merely because they
are tied to their implementation specifics.
--
Stephen Smalley
National Security Agency
On Wed, Jun 06, 2007 at 09:26:26AM -0400, Stephen Smalley wrote:
> On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote:
> > On Tuesday 15 May 2007 11:20, Pavel Machek wrote:
> > > Hi!
> > >
> > > > Pathname matching, transition table loading, profile loading and
> > > > manipulation.
> > >
> > > So we get small interpretter of state machines, and reason we need is
> > > is 'apparmor is misdesigned and works with paths when it should have
> > > worked with handles'.
> >
> > I assume you mean labels instead of handles.
> >
> > AppArmor's design is around paths not labels, and independent of whether or
> > not you like AppArmor, this design leads to a useful security model distinct
> > from the SELinux security model (which is useful in its own ways). The
> > differences between those models cannot be argued away, neither is a subset
> > of the other, and neither is a misdesign. I would be thankful if you could
> > stop spreading this lie.
>
> I have a hard time distinguishing AppArmor's "model" from its
> implementation; every time we suggest that one might emulate much of
> AppArmor's functionality on SELinux (as in SEEdit), someone points to a
> specific characteristic of the AppArmor implementation that cannot be
> emulated in this manner. But is that implementation characteristic an
> actual requirement or just how it happens to have been done to date in
> AA? And I get the impression that even if we extended SELinux in
> certain ways to ease such emulation, the AA folks would never be
> satisfied because the implementation would still differ. Can we
> separate the desired functionality and actual requirements from the
> implementation specifics?
That's a really good point, is there a description of the AA "model"
anywhere that we could see to determine if there really is a way to
possibly use the current SELinux internals to show this model to the
user?
thanks,
greg k-h
On Wednesday 06 June 2007 15:26, Stephen Smalley wrote:
> On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote:
> > [...] SELinux turns pathnames into labels when it
> > initially labels all files (when a policy is rolled out), whereas
> > AppArmor computes the "label" of each file when a file is opened. The two
> > models start to diverge as soon as files are renamed: in SELinux, labels
> > stick with the files. In AppArmor, "labels" stick with the names.
>
> I'd argue a bit with that characterization, given that:
> - in the case of SELinux, the pathname is never used as a basis for
> decisions by the kernel,
Indeed, the kernel component of SELinux only uses file labels for making file
access decisions and not pathnames. But those labels were initially created
by a trusted process (e.g. restorecon) based on pathnames, and this initial
labeling is an essential part of the SELinux model. So in a sense,
disregarding creation and relabeling of files, one could argue that SELinux
makes decisions based on the pathnames that files had when they were labeled.
In SELinux, labels are the only thing that distinguishes between files. So if
at one point you find that you need to distinguish between files that share a
label, you have to split the label and reclassify the files in addition to
adjusting the policy. Again, the usual approach for reclassifying files will
probably be pathname based.
In contrast, AppArmor does not use labels, and the pathnames at the time of
access distinguish between files. Since files do not have labels, no
relabeling is necessary in order to change policy.
> - under AA, each file may have an arbitrary set of "labels" or
> "policies" applied to it depending on what programs are accessing it and
> what names are being used to reference it - there is no system view of
> the subjects and objects and thus no way to identify the overall system
> policy for a given file.
Look at it this way: under SELinux, the set of files that share a label forms
an equivalence class -- they are all treated identically by the system's
security policy. The rules in AppArmor profiles also define equivalence
classes in the sense that they partition the filesystem namespace into sets
of files that are treated identically, but this classification is not
explicit -- the entire rule base contributes to the classification. This
doesn't mean that there is not a global policy, just that the policy is
modeled differently. The equivalence classes are not directly obvious from
the AA profiles.
Contrast this with SEEdit, which compiles AA-style rules into labels (and thus
equivalence classes). The resulting SELinux policy is a static snapshot that
cannot easily accommodate rule base changes, is more limited with respect to
new files (which would likely be fixable), and behaves differently in complex
ways with file renames. What's more, most likely the compiled policy will be
anywhere from very hard to impossible to analyze, so you pretty much lose on
all ends.
I'm not saying that labels are crap and that SELinux is wrong. In fact, labels
are useful for some things like model verification and information flow
analysis. What I'm saying is that AppArmor and SELinux implement different
models, and those models cannot be modeled in terms of each other.
Note that I'm not embarking on implementation aspects here at all, only on the
fundamental model differences.
> - names are far less tranquil than labels.
If I'm getting things right, a tranquil system with respect to labels would be
one that does not permit re-labeling, while a tranquil system with respect to
path names would be one that does not permit renaming. Both approaches would
buy greater analyzability with reduced usability, and both seem unrealistic
to me. SELinux and AppArmor evidently have different goals, and tranquility
is more important to SELinux.
AppArmor is meant to be relatively easy to understand, manage, and customize,
and introducing a labels layer wouldn't help these goals. SELinux is
applicable in areas where AppArmor is not (e.g., MLS), but this comes at a
cost. For me the question is not SELinux or AppArmor, but if AppArmor's
security model is a good solution in common scenarios. In my opinion,
AppArmor is a better answer than SELinux in a number of scenarios. This gives
it value, nonwithstanding the fact that SELinux can be taken further.
Thanks,
Andreas
On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
> AppArmor is meant to be relatively easy to understand, manage, and customize,
> and introducing a labels layer wouldn't help these goals.
Woah, that describes the userspace side of AA just fine, it means
nothing when it comes to the in-kernel implementation. There is no
reason that you can't implement the same functionality using some
totally different in-kernel solution if possible.
> SELinux is applicable in areas where AppArmor is not (e.g., MLS), but
> this comes at a cost. For me the question is not SELinux or AppArmor,
> but if AppArmor's security model is a good solution in common
> scenarios. In my opinion, AppArmor is a better answer than SELinux in
> a number of scenarios. This gives it value, nonwithstanding the fact
> that SELinux can be taken further.
I am still not completely certian that we can not properly implement AA
functionality using a SELinux backend solution. Yes, the current tools
that try to implement this are still lacking, and maybe the kernel needs
to change, but that is possible.
I still want to see a definition of the AA "model" that we can then use
to try to implement using whatever solution works best. As that seems
to be missing the current argument of if AA can or can not be
implemented using SELinux or something totally different should be
stopped.
So, AA developers, do you have such a document anywhere? I know there
are some old research papers, do they properly describe the current
model you are trying to implement here?
thanks,
greg k-h
On Fri, 8 Jun 2007, Greg KH wrote:
> On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
>> AppArmor is meant to be relatively easy to understand, manage, and customize,
>> and introducing a labels layer wouldn't help these goals.
>
> Woah, that describes the userspace side of AA just fine, it means
> nothing when it comes to the in-kernel implementation. There is no
> reason that you can't implement the same functionality using some
> totally different in-kernel solution if possible.
>
>> SELinux is applicable in areas where AppArmor is not (e.g., MLS), but
>> this comes at a cost. For me the question is not SELinux or AppArmor,
>> but if AppArmor's security model is a good solution in common
>> scenarios. In my opinion, AppArmor is a better answer than SELinux in
>> a number of scenarios. This gives it value, nonwithstanding the fact
>> that SELinux can be taken further.
>
> I am still not completely certian that we can not properly implement AA
> functionality using a SELinux backend solution. Yes, the current tools
> that try to implement this are still lacking, and maybe the kernel needs
> to change, but that is possible.
>
> I still want to see a definition of the AA "model" that we can then use
> to try to implement using whatever solution works best. As that seems
> to be missing the current argument of if AA can or can not be
> implemented using SELinux or something totally different should be
> stopped.
>
> So, AA developers, do you have such a document anywhere? I know there
> are some old research papers, do they properly describe the current
> model you are trying to implement here?
Greg,
to implement the AA approach useing SELinux you need to have a way that
files that are renamed or created get tagged with the right label
automaticaly with no possible race condition.
If this can be done then it _may_ be possible to do the job that AA is
aimed at with SELinux, but the work nessasary to figure out what lables
are needed on what file would still make it a non-trivial task.
as I understand it SELinux puts one label on each file, so if you have
three files accessed by two programs such that
program A accesses files X Y
program B accesses files Y Z
then files X Y and Z all need seperate labels with the policy stateing
that program A need to access labels X, Y and program B needs to access
files Y Z
extended out this can come close to giving each file it's own label. AA
essentially does this and calls the label the path and computes it at
runtime instead of storing it somewhere.
David Lang
Hello.
David Lang wrote:
> as I understand it SELinux puts one label on each file, so if you have
> three files accessed by two programs such that
> program A accesses files X Y
> program B accesses files Y Z
>
> then files X Y and Z all need separate labels with the policy stateing
> that program A need to access labels X, Y and program B needs to access
> files Y Z
>
> extended out this can come close to giving each file it's own label. AA
> essentially does this and calls the label the path and computes it at
> runtime instead of storing it somewhere.
I tried to give each file it's own label, but I couldn't do it.
http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf
There are many elements that forms too strong barrier between pathname and labels,
such as bind-mounts, hard links, newly created files, renamed files, temporary files and so on.
So I gave up giving each file a label that can be used as an identifier,
and took an approach to forbid unneeded mount operations, unneeded link operations,
unneeded renaming operations to keep the pathname represent it's own identifier as much as possible.
Thanks.
On Sat, 9 Jun 2007 11:01:41 +0900
Tetsuo Handa <[email protected]> wrote:
>From the discussion so far, it seems that the different "model" that AA
is trying to implement, is to do in one step what SELinux does in two
steps; that is trying to combine labelling and enforcement into a
single step. If this is so, then why can't it just feed its automatic
labelling into SELinux enforcement code?
> I tried to give each file it's own label, but I couldn't do it.
> http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf
That paper seems entirely focused on the automatic generation of policy,
and doesn't seem to help the discussion along. For instance, there may
be a way to implement AA on top of SELinux _without_ giving each and
every file its own label.
> There are many elements that forms too strong barrier between pathname and labels,
> such as bind-mounts, hard links, newly created files, renamed files, temporary files and so on.
> So I gave up giving each file a label that can be used as an identifier,
> and took an approach to forbid unneeded mount operations, unneeded link operations,
> unneeded renaming operations to keep the pathname represent it's own identifier as much as possible.
AA must have a function that decides the security rights for any given
path in order to make its enforcement decisions. It must surely be able
to deal with all those things you listed above (bind-mounts,hard links etc).
So why can't those decisions be turned into labels that are fed into SELinux
enforcement code?
Sean.
On Fri, 8 Jun 2007, Sean wrote:
>
> On Sat, 9 Jun 2007 11:01:41 +0900
> Tetsuo Handa <[email protected]> wrote:
>
>
> From the discussion so far, it seems that the different "model" that AA
> is trying to implement, is to do in one step what SELinux does in two
> steps; that is trying to combine labelling and enforcement into a
> single step. If this is so, then why can't it just feed its automatic
> labelling into SELinux enforcement code?
>
>> I tried to give each file it's own label, but I couldn't do it.
>> http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf
>
> That paper seems entirely focused on the automatic generation of policy,
> and doesn't seem to help the discussion along. For instance, there may
> be a way to implement AA on top of SELinux _without_ giving each and
> every file its own label.
>
>> There are many elements that forms too strong barrier between pathname and labels,
>> such as bind-mounts, hard links, newly created files, renamed files, temporary files and so on.
>> So I gave up giving each file a label that can be used as an identifier,
>> and took an approach to forbid unneeded mount operations, unneeded link operations,
>> unneeded renaming operations to keep the pathname represent it's own identifier as much as possible.
>
> AA must have a function that decides the security rights for any given
> path in order to make its enforcement decisions. It must surely be able
> to deal with all those things you listed above (bind-mounts,hard links etc).
> So why can't those decisions be turned into labels that are fed into SELinux
> enforcement code?
with AA hardlinks are effectivly different labels on the same file
one of the big problems with SELinux is what label to put on new files
(including temp files), the AA approach avoids this (frequent) problem
entirely. In exchange AA picks up the (infrequent) problems of bind-mounts
and hard-link creation. People have tried to equate these prolems to show
that AA has just as many problems as SELinux, but you can run systems for
decades without creating hard-links or bind-mounts
also you seriously misunderstand the AA approach
AA does NOT try to create a security policy for every file on the system.
Instead AA policies are based on specific programs, and each policy states
what files that program is allowed to access.
if you are useing AA to secure all exposed services on a box you don't
have to try to write a policy to describe what gcc is allowed to access
(unless through policy you give one of your exposed services permission to
run gcc, and even then I'm not sure if gcc would inherit restrictions
from it's parent or just use it's own)
the resulting policy is much easier to understand (and therefor check)
becouse it is orders of magnatude smaller then any comprehensive SELinux
policy.
the AA policy is also much easier to understand becouse you can look at it
in pieces, understand that piece, and then forget it and move on to the
next piece.
for example, if you write a policy for apache that limits it's access to
it's log files, install directories, and document root. then you write a
policy for your log analysis tool to access it's libraries, report
directories (under the apache document root) and the apache log files
(read only), these two policies are independant, you don't have to think
about one while creating the other (which you would have to do if you had
to put one label on apache binaries, another on normal web documents, a
third on the reports, a fourth on the log files, and a fifth on the
binaries for the log analysis tool. and this is ignoring any overlap in
libraries!)
AA also lets a sysadmin dip their toe in the water and just write a policy
for Apache, not for anything else, then write a policy for firefox, then
write a policy for their mail client, then for bittorrent, etc. there is
no need or push to try and secure everything all at once, and no need to
re-label files (and change any policies that used the old labels) when
you discover a new interaction.
David Lang
On Fri, 8 Jun 2007 21:56:06 -0700 (PDT)
[email protected] wrote:
>
> with AA hardlinks are effectivly different labels on the same file
So what? SELinux can be be altered to accept whatever label you generate.
Pass it whatever label you want.
> one of the big problems with SELinux is what label to put on new files
> (including temp files), the AA approach avoids this (frequent) problem
> entirely. In exchange AA picks up the (infrequent) problems of bind-mounts
> and hard-link creation. People have tried to equate these prolems to show
> that AA has just as many problems as SELinux, but you can run systems for
> decades without creating hard-links or bind-mounts
You are thinking about the way SELinux operates today, not how it might
operate to accommodate AA inclusion in the kernel. Instead of SELinux
always obtaining labels from file attributes, it could ask AA for them
and you could generate them however you like.
> also you seriously misunderstand the AA approach
>
> AA does NOT try to create a security policy for every file on the system.
>
> Instead AA policies are based on specific programs, and each policy states
> what files that program is allowed to access.
please read a bit more carefully, I was responding to someone else who
made that claim.
> if you are useing AA to secure all exposed services on a box you don't
> have to try to write a policy to describe what gcc is allowed to access
> (unless through policy you give one of your exposed services permission to
> run gcc, and even then I'm not sure if gcc would inherit restrictions
> from it's parent or just use it's own)
>
> the resulting policy is much easier to understand (and therefor check)
> becouse it is orders of magnatude smaller then any comprehensive SELinux
> policy.
>
> the AA policy is also much easier to understand becouse you can look at it
> in pieces, understand that piece, and then forget it and move on to the
> next piece.
Nobody is asking you to change the AA policy file. It lives in user space.
But i fail to see the problem in translating it into SELinux terms for
the user transparently.
> for example, if you write a policy for apache that limits it's access to
> it's log files, install directories, and document root. then you write a
> policy for your log analysis tool to access it's libraries, report
> directories (under the apache document root) and the apache log files
> (read only), these two policies are independant, you don't have to think
> about one while creating the other (which you would have to do if you had
> to put one label on apache binaries, another on normal web documents, a
> third on the reports, a fourth on the log files, and a fifth on the
> binaries for the log analysis tool. and this is ignoring any overlap in
> libraries!)
Again, try to think outside the box a bit. This isn't about using SELinux
as it exists today. But imagine an SELinux that would ask you to
supply a security label for each file _instead_ of looking up that label
itself. Wouldn't that let you implement everything you wanted while still
using much of the SELinux infrastructure that is already in the kernel?
> AA also lets a sysadmin dip their toe in the water and just write a policy
> for Apache, not for anything else, then write a policy for firefox, then
> write a policy for their mail client, then for bittorrent, etc. there is
> no need or push to try and secure everything all at once, and no need to
> re-label files (and change any policies that used the old labels) when
> you discover a new interaction.
And so it could remain; this is about implementation, not model.
Sean
On Fri, 8 Jun 2007, Greg KH wrote:
> I still want to see a definition of the AA "model" that we can then use
> to try to implement using whatever solution works best. As that seems
> to be missing the current argument of if AA can or can not be
> implemented using SELinux or something totally different should be
> stopped.
the way I would describe the difference betwen AA and SELinux is:
SELinux is like a default allow IPS system, you have to describe
EVERYTHING to the system so that it knows what to allow and what to stop.
AA is like a default deny firewall, you describe what you want to happen,
and it blocks everything else without you even having to realize that it's
there.
now I know that this isn't a perfect analyogy, that SELinux doesn't allow
something to happen unless it's been told to let it, but in terms of
complexity and the amount of work to configure things I think the analogy
is close.
the fact that the SELinux policy _will_ affect the entire systems means
one of two things.
1. you have a policy that exactly describes how every part of the system
operates
or
2. you have a policy that's exessivly permissive in some parts of the
system becouse 'that works' and you either don't understand that part of
the system well enough, or don't have time to write a more complete
policy.
I would argue that with the number of files on a system nowdays (483,000
on my 'minimalistic' gentoo server, 442,000 on my slackware laptop,
800,000 on a ubuntu server at work) it's not possible to do #1, so any
deployed policy (especially one done by a disto that needs to work for all
it's users) is going to follow #2, frequently to the point where it's not
really adding much security.
David Lang
On Sat, 9 Jun 2007, Sean wrote:
>>
>> the AA policy is also much easier to understand becouse you can look at it
>> in pieces, understand that piece, and then forget it and move on to the
>> next piece.
>
> Nobody is asking you to change the AA policy file. It lives in user space.
> But i fail to see the problem in translating it into SELinux terms for
> the user transparently.
>> for example, if you write a policy for apache that limits it's access to
>> it's log files, install directories, and document root. then you write a
>> policy for your log analysis tool to access it's libraries, report
>> directories (under the apache document root) and the apache log files
>> (read only), these two policies are independant, you don't have to think
>> about one while creating the other (which you would have to do if you had
>> to put one label on apache binaries, another on normal web documents, a
>> third on the reports, a fourth on the log files, and a fifth on the
>> binaries for the log analysis tool. and this is ignoring any overlap in
>> libraries!)
>
> Again, try to think outside the box a bit. This isn't about using SELinux
> as it exists today. But imagine an SELinux that would ask you to
> supply a security label for each file _instead_ of looking up that label
> itself. Wouldn't that let you implement everything you wanted while still
> using much of the SELinux infrastructure that is already in the kernel?
so are you suggesting that SELinux would call out to userspace for every
file open to get the label for that file?
just off the top of my head
what would all these kernel->userspace->kernel transitions do to
performance?
would SELinux give userspace the full path to that file?
if so wouldn't it have to implement most of what AA adds to do this?
if not how would userspace figure out what label to hand back without this
info?
how would SELinux figure out the permissions for the userspace Daemon?
how would you change both the rules for labels in the kernel and the
policy for assigning labels in userspace without any race conditions?
>> AA also lets a sysadmin dip their toe in the water and just write a policy
>> for Apache, not for anything else, then write a policy for firefox, then
>> write a policy for their mail client, then for bittorrent, etc. there is
>> no need or push to try and secure everything all at once, and no need to
>> re-label files (and change any policies that used the old labels) when
>> you discover a new interaction.
>
> And so it could remain; this is about implementation, not model.
yes, you could add all the AA code to SELinux and then say that the result
is implemented in SELinux, you may even save a little bit of code in some
parts of it (but I would argue that you add more code in others, say for
the userpace interface and userspace labeling code), but the result
wouldn't be in the spirit of SELinux.
it may be possible to write something that resembles AA in SELinux policy
(once you solve the problem of how to label newly created files securely),
but it's also possible to write a webserver in COBOL to run out of inetd,
that doesn't mean that it makes any sort of sense to do either one.
on the other hand, it may be a good idea. let's see how people really use
AA once they have it available and the SELinux folks can work on
duplicating the functionality, if they do then the existing AA interface
could be phased out over time, or the internal implementation could
change. but arguing that SELinux _may_ be able to do the job of AA
_someday_ should not prevent AA from being included today (especially when
so many of the SELinux developers are so opposed to the very concept of
AA, which doesn't indicate that they are about to rush out and implement
the pieces needed to make it work)
David Lang
On Fri, 8 Jun 2007 22:38:57 -0700 (PDT)
[email protected] wrote:
> so are you suggesting that SELinux would call out to userspace for every
> file open to get the label for that file?
>
No, i'm not. You must already have a kernel function in the current
implementation of AA that decides the proper policy for each path. Why
not use it to feed labels into SELinux.
Sean
On Fri, 8 Jun 2007 22:18:40 -0700 (PDT)
[email protected] wrote:
> the way I would describe the difference betwen AA and SELinux is:
>
> SELinux is like a default allow IPS system, you have to describe
> EVERYTHING to the system so that it knows what to allow and what to stop.
>
> AA is like a default deny firewall, you describe what you want to happen,
> and it blocks everything else without you even having to realize that it's
> there.
>
> now I know that this isn't a perfect analyogy, that SELinux doesn't allow
> something to happen unless it's been told to let it, but in terms of
> complexity and the amount of work to configure things I think the analogy
> is close.
It must be drop dead simple to modify SELinux to be default-deny. That
seems like it could be done in a small patch instead of requiring a huge
new infrastructure.
Let's assume that everyone agrees that AA is a good idea. Which parts of it
absolutely can't be implemented in terms of SELinux? SELinux isn't fixed in
stone, it can be altered if necessary to accommodate AA (as in the example
above of becoming default-deny).
Sean.
On Sat, 9 Jun 2007, Sean wrote:
>> so are you suggesting that SELinux would call out to userspace for every
>> file open to get the label for that file?
>>
>
> No, i'm not. You must already have a kernel function in the current
> implementation of AA that decides the proper policy for each path. Why
> not use it to feed labels into SELinux.
if it was this easy just have SELinux set the label == path
you first need to figure out what the path is. right now this can't be
done, the AA paches provide this capability.
second, the AA policies aren't based just on the path, they are based on
the program accessing the path, then the path. you can have two different
policies for two different programs accessing the same path, but for most
programs (although, not nessasarily most activity) there will be no
policy, and therefor no need to check the path.
but even if you did these things, why would it be an advantage to use a
mechanism to create a dummy label and pass it off to different code rather
then just decideing at that point? once the AA code knows what the policy
for this path is for this program (which it would need to know to set the
label) how is it a win to pass this off to another chunk of code? you
would also need to make sure that the SELinux code didn't try to cache the
label for future use either, becouse in the future the access may be from
another program and so the policy that's needed is different.
David Lang
On Sat, 9 Jun 2007, Sean wrote:
> On Fri, 8 Jun 2007 22:18:40 -0700 (PDT)
> [email protected] wrote:
>
>> the way I would describe the difference betwen AA and SELinux is:
>>
>> SELinux is like a default allow IPS system, you have to describe
>> EVERYTHING to the system so that it knows what to allow and what to stop.
>>
>> AA is like a default deny firewall, you describe what you want to happen,
>> and it blocks everything else without you even having to realize that it's
>> there.
>>
>> now I know that this isn't a perfect analyogy, that SELinux doesn't allow
>> something to happen unless it's been told to let it, but in terms of
>> complexity and the amount of work to configure things I think the analogy
>> is close.
>
> It must be drop dead simple to modify SELinux to be default-deny. That
> seems like it could be done in a small patch instead of requiring a huge
> new infrastructure.
did you read my explination of the analogy?
> Let's assume that everyone agrees that AA is a good idea. Which parts of it
> absolutely can't be implemented in terms of SELinux? SELinux isn't fixed in
> stone, it can be altered if necessary to accommodate AA (as in the example
> above of becoming default-deny).
what SELinux cannot do is figure out what label to assign a new file.
but the bigger problem in changing SELinux to behave like AA is that the
SELinux people disagree with the concept of AA. they don't believe that
it's secure, so why would they add useless bloat that would only
complicate their code and make systems less secure? I don't happen to
agree with their opinion of AA obviously, but they have the right to their
opinion, and it is their code. why should they be asked to implement and
support something they disagree with so fundamentally?
remember that the security hooks in the kernel are not SELinux API's, they
are the Loadable Security Model API. What the AA people are asking for is
for the LSM API to be modified enough to let their code run (after that
(and working in parallel) they will work on getting the rest of their code
approved for the kernel, but the LSM hooks are the most critical)
David Lang
On Sat, 9 Jun 2007 00:04:15 -0700 (PDT)
[email protected] wrote:
> if it was this easy just have SELinux set the label == path
> you first need to figure out what the path is. right now this can't be
> done, the AA paches provide this capability.
The question is: why not just extend SELinux to include AA functionality
rather than doing a whole new subsystem. What exactly about AA demands
an entire new infrastructure rather than just building on what already
exists in the kernel?
> second, the AA policies aren't based just on the path, they are based on
> the program accessing the path, then the path. you can have two different
> policies for two different programs accessing the same path, but for most
> programs (although, not nessasarily most activity) there will be no
> policy, and therefor no need to check the path.
It seems the main purported advantage of AA is it doesn't require maintaining
labels on files etc. In fact, that's the only conceptual difference I can
see other than a simpler policy file format. So why not just make an AA
extension to SELinux that implements this main difference (ie. create labels
on the fly).
Then have a userspace program that converts the pretty-peace-and-love
AA policy file format into the baby-killing SELinux format and feed it
into the kernel.
All of a sudden you've implemented the main features of AA with very
few changes to the kernel. It should be more maintainable, and much
easier to get accepted into the kernel.
> but even if you did these things, why would it be an advantage to use a
> mechanism to create a dummy label and pass it off to different code rather
> then just decideing at that point?
Because it requires you to reimplement much of what is already in the kernel.
It requires you to be able to understand an entire new policy mechanism
instead of just piggybacking on what already exists.
> once the AA code knows what the policy
> for this path is for this program (which it would need to know to set the
Again you're only looking at the way the AA code is _today_. If it were
refactored to be an extension of SELinux, there would be no reason for the
AA kernel code to know any policy whatsoever. All it would need to know
is a path-to-label mapping. SELinux would then enforce the AA policy
that it received from your userspace tool that translates your native
AA policy format into SELinux-lingo.
> label) how is it a win to pass this off to another chunk of code? you
It's a win because the policy enforcement code is already in the kernel.
All you have to do is extend SELinux to create labels on the fly and provide
a userspace tool to convert the nice AA policy files into something SELinux
can use.
> would also need to make sure that the SELinux code didn't try to cache the
> label for future use either, becouse in the future the access may be from
> another program and so the policy that's needed is different.
You seem to be quibbling over small little unimportant details and refusing
to part with your current implementation. It would seem the easiest way to
get the functionality you want into the kernel is to be a bit more flexible
on implementation.
Sean
On Sat, 9 Jun 2007 00:13:22 -0700 (PDT)
[email protected] wrote:
> did you read my explination of the analogy?
It was a rather poor analogy i'm afraid. But the point i make still stands.
So far you've failed to show any reason SELinux can't be reasonably extended
to handle all the features you care about.
> what SELinux cannot do is figure out what label to assign a new file.
That would be the job of your AA extension.
> but the bigger problem in changing SELinux to behave like AA is that the
> SELinux people disagree with the concept of AA. they don't believe that
> it's secure, so why would they add useless bloat that would only
> complicate their code and make systems less secure? I don't happen to
> agree with their opinion of AA obviously, but they have the right to their
> opinion, and it is their code. why should they be asked to implement and
> support something they disagree with so fundamentally?
So now you're claiming the real reason to let AA into the kernel is
politics?
Just show that the feature can be easily added to SELinux and made as an
option for the end user to choose and it should go a long way to silencing
the opponents.
>
> remember that the security hooks in the kernel are not SELinux API's, they
> are the Loadable Security Model API. What the AA people are asking for is
> for the LSM API to be modified enough to let their code run (after that
> (and working in parallel) they will work on getting the rest of their code
> approved for the kernel, but the LSM hooks are the most critical)
Remember that the SELinux API's essentially belong to everyone under the GPL.
So its not an excuse for falling into NIH syndrome and putting a bunch of
new stuff into the kernel that could instead be added as a small
extension to what already exists.
Sean
On Sat, 9 Jun 2007, Sean wrote:
> On Sat, 9 Jun 2007 00:04:15 -0700 (PDT)
> [email protected] wrote:
>
>
>> if it was this easy just have SELinux set the label == path
>> you first need to figure out what the path is. right now this can't be
>> done, the AA paches provide this capability.
>
> The question is: why not just extend SELinux to include AA functionality
> rather than doing a whole new subsystem. What exactly about AA demands
> an entire new infrastructure rather than just building on what already
> exists in the kernel?
>
>> second, the AA policies aren't based just on the path, they are based on
>> the program accessing the path, then the path. you can have two different
>> policies for two different programs accessing the same path, but for most
>> programs (although, not nessasarily most activity) there will be no
>> policy, and therefor no need to check the path.
>
> It seems the main purported advantage of AA is it doesn't require maintaining
> labels on files etc. In fact, that's the only conceptual difference I can
> see other than a simpler policy file format. So why not just make an AA
> extension to SELinux that implements this main difference (ie. create labels
> on the fly).
becouse the SELinux people don't want to have this in their code for one
thing.
you seem to be ignoring the SELinux people who say that pathnames are
fundamentally different from labels, labels stay with the data if the file
is renamed, path names do not. multiple hard-links to the same file will
always have the same label for SELinux, but could have very different
permissions with AA
labels are part of policy, policy is not supposed to be decided by the
kernel.
SELinux treats all files with the same label the same. to have the same
ability to treat every file differntly that AA has SELinux would have to
give every file a different label.
> Then have a userspace program that converts the pretty-peace-and-love
> AA policy file format into the baby-killing SELinux format and feed it
> into the kernel.
>
> All of a sudden you've implemented the main features of AA with very
> few changes to the kernel. It should be more maintainable, and much
> easier to get accepted into the kernel.
how will you know how many labels you need to put into your policy that
you load into the kernel?
how will the kernel figure out what label to use for a file
and the userspace code that converts the policy needs to know the names
when it feeds the policy into the kernel.
and you still need to implement the new LSM hooks that AA is asking for to
figure out what the path to a file is.
>> but even if you did these things, why would it be an advantage to use a
>> mechanism to create a dummy label and pass it off to different code rather
>> then just decideing at that point?
>
> Because it requires you to reimplement much of what is already in the kernel.
> It requires you to be able to understand an entire new policy mechanism
> instead of just piggybacking on what already exists.
the policy mechanism is supposed to be the LSM hooks, and AA is trying to
re-use them.
>> once the AA code knows what the policy
>> for this path is for this program (which it would need to know to set the
>
> Again you're only looking at the way the AA code is _today_. If it were
> refactored to be an extension of SELinux, there would be no reason for the
> AA kernel code to know any policy whatsoever. All it would need to know
> is a path-to-label mapping. SELinux would then enforce the AA policy
> that it received from your userspace tool that translates your native
> AA policy format into SELinux-lingo.
after you change SELinux to be able to do everything that AA does then you
can tell SELinux to act like AA, true but irrelavent.
>> label) how is it a win to pass this off to another chunk of code? you
>
> It's a win because the policy enforcement code is already in the kernel.
> All you have to do is extend SELinux to create labels on the fly and provide
> a userspace tool to convert the nice AA policy files into something SELinux
> can use.
>
>> would also need to make sure that the SELinux code didn't try to cache the
>> label for future use either, becouse in the future the access may be from
>> another program and so the policy that's needed is different.
>
> You seem to be quibbling over small little unimportant details and refusing
> to part with your current implementation. It would seem the easiest way to
> get the functionality you want into the kernel is to be a bit more flexible
> on implementation.
first off, and for the record, it's not _my_ implementation. I have
nothing to do with writing AA.
I am just someone who manages hundreds of servers for which AA would be a
good fit. In the past I've gone to a lot of effort to get less security
then AA would provide to implement seperate services in seperate chroot
sandboxes. I'm looking for easier and better options, I've looked at
SELinux and don't believe that I can produce a reasonable policy in a
reasonable amount of time (and I don't trust distro vendors to do it for
me, they have to allow a lot of things that don't make sense on my
systems, and I occasionally need to allow something that wouldn't make
sense in the general case, let alone all the software I run that the disto
doesn't know anything about)
chroot sandboxes, virtual machines, containers all have the problem that
when you need to have more then one application interacting they need to
be put togeather and the basic mechanism doesn't provide you any security
against each other.
SELinux is aiming for 'perfect' security, I'll readily admit that, just
like I'll admit that AA is only aiming for 'good enough' security, but
that 'good enough' security would help me and I don't see any way to get
to SELinux's 'perfect' security.
I also don't care about the details of how it gets implemented, but when
the AA people have a working implementation, and the SELinux people are
strongly opposed to the concept, I don't see any advantage in trying to
get the AA people to throw away a lot of their working code to try and get
people (many of who have be very insulting frankly) to accept such
fandamental changes.
if the SELinux people had responded to the announcement of AA with "that's
a nice idea, if we add these snippits from your code to SELinux then we
can do the same thing" it would be a very different story.
but as always patches talk louder then anything else, if you believe that
the efforts should be combined so strongly why don't you start submitting
the appropriate patches to SELinux to make it able to do what AA does?
David Lang
On Sat, 9 Jun 2007, Sean wrote:
>> remember that the security hooks in the kernel are not SELinux API's, they
>> are the Loadable Security Model API. What the AA people are asking for is
>> for the LSM API to be modified enough to let their code run (after that
>> (and working in parallel) they will work on getting the rest of their code
>> approved for the kernel, but the LSM hooks are the most critical)
>
> Remember that the SELinux API's essentially belong to everyone under the GPL.
> So its not an excuse for falling into NIH syndrome and putting a bunch of
> new stuff into the kernel that could instead be added as a small
> extension to what already exists.
but the SELinux API's are not the core security API's in Linux, the LSM
API's are. and AA is useing the LSM API's (extending them where they and
SELinux don't do what's needed)
David Lang
On Sat, 9 Jun 2007 01:06:09 -0700 (PDT)
[email protected] wrote:
> but the SELinux API's are not the core security API's in Linux, the LSM
> API's are. and AA is useing the LSM API's (extending them where they and
> SELinux don't do what's needed)
>
Calling LSM "core" and pretending that SELinux can't do 90% of what you
want doesn't change the facts on the ground. Clinging to the current AA
implementation instead of honestly considering reasonable alternatives
does not inspire confidence or teamwork.
Sean.
On Sat, 9 Jun 2007 01:03:15 -0700 (PDT)
[email protected] wrote:
> becouse the SELinux people don't want to have this in their code for one
> thing.
Tuff nuggies to the SELinux people.. Show them code good enough they'd be
embarrassed to reject.
> you seem to be ignoring the SELinux people who say that pathnames are
> fundamentally different from labels, labels stay with the data if the file
> is renamed, path names do not. multiple hard-links to the same file will
> always have the same label for SELinux, but could have very different
> permissions with AA
>
> labels are part of policy, policy is not supposed to be decided by the
> kernel.
Not sure why you're rehashing this. We all know that not everyone
agrees with AA. The point is users should have a choice.. choice is
good. But that's not a justification for bloating the kernel with
a bunch of code that isn't needed and can be refactored into a
small extension of what already exists.
> SELinux treats all files with the same label the same. to have the same
> ability to treat every file differntly that AA has SELinux would have to
> give every file a different label.
I'm not convinced in practice you really need a unique label for every
file. Large swathes of the system would have a shared label etc.. So
let's not get caught up on theoretical arguments that don't really play
in practice. Has anyone on the AA team actually _tried_ to extend
SELinux instead of reinventing the wheel?
> how will you know how many labels you need to put into your policy that
> you load into the kernel?
>
> how will the kernel figure out what label to use for a file
The AA extension will have a path-to-label mapping. Conceptually that's
exactly what its doing now. Look at the arguments by AA proponents that
the only difference between the AA method and SELinux is _when_ those
labels are created... Sorry i don't have a link handy, but i can dig one
up if you dispute that this argument has been made by the AA folks.
> and the userspace code that converts the policy needs to know the names
> when it feeds the policy into the kernel.
> and you still need to implement the new LSM hooks that AA is asking for to
> figure out what the path to a file is.
True, but so what?
> the policy mechanism is supposed to be the LSM hooks, and AA is trying to
> re-use them.
Who says that's what is "supposed" to be in all situations? It makes more
sense to target the best API that lets you implement the features you want.
> after you change SELinux to be able to do everything that AA does then you
> can tell SELinux to act like AA, true but irrelavent.
BS. All we're talking about is an extension that allows SELinux to
generate labels on the fly. That goes most the way towards giving
you all the functionality you're after and should be a much smaller patch
in the end, reusing code that already exists in the kernel.
> first off, and for the record, it's not _my_ implementation. I have
> nothing to do with writing AA.
>
> I am just someone who manages hundreds of servers for which AA would be a
> good fit. In the past I've gone to a lot of effort to get less security
> then AA would provide to implement seperate services in seperate chroot
> sandboxes. I'm looking for easier and better options, I've looked at
> SELinux and don't believe that I can produce a reasonable policy in a
> reasonable amount of time (and I don't trust distro vendors to do it for
> me, they have to allow a lot of things that don't make sense on my
> systems, and I occasionally need to allow something that wouldn't make
> sense in the general case, let alone all the software I run that the disto
> doesn't know anything about)
Whoa. Again you're mistaking the current state of SELinux, rather than
SELinux + AA extension. If such a beast provides the same features you
get with the current AA implementation, why would you care?
> chroot sandboxes, virtual machines, containers all have the problem that
> when you need to have more then one application interacting they need to
> be put togeather and the basic mechanism doesn't provide you any security
> against each other.
>
> SELinux is aiming for 'perfect' security, I'll readily admit that, just
> like I'll admit that AA is only aiming for 'good enough' security, but
> that 'good enough' security would help me and I don't see any way to get
> to SELinux's 'perfect' security.
All that is irrelevant to the discussion though.
> Also don't care about the details of how it gets implemented, but when
> the AA people have a working implementation, and the SELinux people are
> strongly opposed to the concept, I don't see any advantage in trying to
> get the AA people to throw away a lot of their working code to try and get
> people (many of who have be very insulting frankly) to accept such
> fandamental changes.
But "working implementation" is _not_ the criteria for acceptance into
the kernel and that's what this discussion is about.
> if the SELinux people had responded to the announcement of AA with "that's
> a nice idea, if we add these snippits from your code to SELinux then we
> can do the same thing" it would be a very different story.
To be fair, that's not their job.
> but as always patches talk louder then anything else, if you believe that
> the efforts should be combined so strongly why don't you start submitting
> the appropriate patches to SELinux to make it able to do what AA does?
Because i'm not the one trying to get something into the kernel. I'm not
the one who has to show that my patches are reasonable and make best use
of the current kernel infrastructure possible.
Sean
Sean wrote:
> All of a sudden you've implemented the main features of AA with very
> few changes to the kernel. It should be more maintainable, and much
> easier to get accepted into the kernel.
Do you agree with passing "struct vfsmount" to VFS helper functions and LSM hooks
and introducing d_namespace_path() so that the AA extension can calculate the requested pathname
and map the requested pathname to SELinux's labels?
On Sat, 9 Jun 2007 20:26:57 +0900
Tetsuo Handa <[email protected]> wrote:
> Sean wrote:
> > All of a sudden you've implemented the main features of AA with very
> > few changes to the kernel. It should be more maintainable, and much
> > easier to get accepted into the kernel.
> Do you agree with passing "struct vfsmount" to VFS helper functions and LSM hooks
> and introducing d_namespace_path() so that the AA extension can calculate the requested pathname
> and map the requested pathname to SELinux's labels?
>
Frankly i'm not in a position to judge, but if that's the best way to provide
the desired functionality, then it sounds good. But please make sure you
bounce this all off someone who actually knows what they're talking about. ;o)
Really I was just casually following along this ongoing conversation and had
a more conceptual/design question about how things were implemented. A few
people explained how AA labelling at "runtime" wasn't conceptually very
different than what SELinux did. All that begged the question as to why
that functionality couldn't just be tacked on to SELinux?
Sean
On Sat, 9 Jun 2007, Sean wrote:
> On Sat, 9 Jun 2007 20:26:57 +0900
> Tetsuo Handa <[email protected]> wrote:
>
>> Sean wrote:
>>> All of a sudden you've implemented the main features of AA with very
>>> few changes to the kernel. It should be more maintainable, and much
>>> easier to get accepted into the kernel.
>> Do you agree with passing "struct vfsmount" to VFS helper functions and LSM hooks
>> and introducing d_namespace_path() so that the AA extension can calculate the requested pathname
>> and map the requested pathname to SELinux's labels?
>>
>
> Frankly i'm not in a position to judge, but if that's the best way to provide
> the desired functionality, then it sounds good. But please make sure you
> bounce this all off someone who actually knows what they're talking about. ;o)
> Really I was just casually following along this ongoing conversation and had
> a more conceptual/design question about how things were implemented. A few
> people explained how AA labelling at "runtime" wasn't conceptually very
> different than what SELinux did. All that begged the question as to why
> that functionality couldn't just be tacked on to SELinux?
Sean,
since you aren't in a position to judge what's acceptable and I'm not in
a position to change code our exchange is pointless.
I apologize to the list for the excessive messasges.
David Lang
On Saturday 09 June 2007 02:17, Greg KH wrote:
> On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
> > AppArmor is meant to be relatively easy to understand, manage, and
> > customize, and introducing a labels layer wouldn't help these goals.
>
> Woah, that describes the userspace side of AA just fine, it means
> nothing when it comes to the in-kernel implementation. There is no
> reason that you can't implement the same functionality using some
> totally different in-kernel solution if possible.
I agree that the in-kernel implementation could use different abstractions
than user-space, provided that the underlying implementation details can be
hidden well enough. The key phrase here is "if possible", and in fact "if
possible" is much too strong: very many things in software are possible,
including user-space drives and a stable kernel module ABI. Some things make
sense; others are genuinely bad ideas while still possible.
The things in my reply you chose not to quote make up the essential part of
the model, argue why mapping from an AppArmor-like user-space to a
label-based in-kernel model is fundamentally hard, how implementation details
cannot be hidden, and how such a mapping would lead to disadvantages no
matter which way you look at it.
> > SELinux is applicable in areas where AppArmor is not (e.g., MLS), but
> > this comes at a cost. For me the question is not SELinux or AppArmor,
> > but if AppArmor's security model is a good solution in common
> > scenarios. In my opinion, AppArmor is a better answer than SELinux in
> > a number of scenarios. This gives it value, nonwithstanding the fact
> > that SELinux can be taken further.
>
> I am still not completely certian that we can not properly implement AA
> functionality using a SELinux backend solution. Yes, the current tools
> that try to implement this are still lacking, and maybe the kernel needs
> to change, but that is possible.
I did not pull all of this out of my hat ad hoc. The AppArmor team spent a
fair amount of time researching various ways how AppArmor-like semantics
could be implemented on top of SELinux, as well as ways how AppArmor could be
implemented better. We *really* tried hard. The reason why we are still
proposing this non-SELinux approach is because none of the alternatives
worked out.
If things were as simple as mapping an AppArmor frontend to the SELinux
backend, even with extensions to the SELinux backend (and I know that it
wouldn't be impossible to extend SELinux in reasonable ways), this would
indeed be nice. The issues that SEEdit is having unfortunately only confirm
what we were already certain to know: it just doesn't work.
> I still want to see a definition of the AA "model" that we can then use
> to try to implement using whatever solution works best. As that seems
> to be missing the current argument of if AA can or can not be
> implemented using SELinux or something totally different should be
> stopped.
There is no need to start all over implementing something from scratch. People
have already tried emulating AppArmor on top of SELinux, and SEEdit is the
current best result. All it takes is the time to understand the SELinux and
AppArmor models. From there it is not hard to see that SEEdit does the best
it can do, and how it is just not a good idea. There are a few things that
could be improved with additional SELinux in-kernel infrastructure, but the
fundamental problems remain. It just remains a very bad idea.
> So, AA developers, do you have such a document anywhere? I know there
> are some old research papers, do they properly describe the current
> model you are trying to implement here?
We wrote an AppArmor technical documentation, and it was posted as part of the
last two AppArmor submissions. It describes the model, and how the model is
implemented. If you need a better description of the model, let us know how
we can improve it.
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
What you'll not find in there is a detailed comparison between AppArmor and
SELinux, and the problems that emulating AppArmor on top of SELinux would
cause -- some details on that can be found in the SEEdit documentation, and
in addition, this LKML thread seems best to me at the moment.
Andreas
On Saturday 09 June 2007 10:10, Sean wrote:
> Clinging to the current AA implementation instead of honestly considering
> reasonable alternatives does not inspire confidence or teamwork.
What you imply is pretty insulting. I can assure you we looked into many
possible implementation choices, and we considered a fair number of
alternatives.
Have you seen the ``AppArmor FAQ'' thread?
Andreas
[email protected] wrote:
> On Sat, 9 Jun 2007, Sean wrote:
> <snip>
>
> what SELinux cannot do is figure out what label to assign a new file.
>
Nit: SELinux figures out what to label new files fine, just not based on
the name. This works in most cases, eg., when user_t creates a file in
/tmp it becomes user_tmp_t, incidentally this is something that AA
cannot handle, if the filenames aren't normalized (they normally
aren't). For example, my ssh agent socket is stored in
/tmp/ssh-XXXXXXXX, where the X's are random characters, AA can't
differentiate admin ssh agents from unprivileged user ssh agents,
showing a serious flaw in their model.
The complaint is that name-based labeling doesn't currently exist (and
as Sean has stated that doesn't mean it _can't_ exist, just that it
doesn't currently). In practice this has not been as big of an issue as
you are making it out to be. Granted restorecond has a tiny race, and I
wouldn't recommend using it on very security sensitive files but for
usability having it relabel user_home_t to user_http_content_t isn't a
problem (and causes no security issues).
On Jun 09, 2007, at 01:18:40, [email protected] wrote:
> SELinux is like a default allow IPS system, you have to describe
> EVERYTHING to the system so that it knows what to allow and what to
> stop.
WRONG. You clearly don't understand SELinux at all. Try booting in
enforcing mode with an empty policy file (well, not quite empty,
there are a few mandatory labels you have to create before it's a
valid policy file). /sbin/init will load the initial policy, attempt
to re-exec() itself... and promptly grind to a halt. End-of-story.
Typical "targetted" policies leave all user logins as unrestricted,
adding security for daemons but not getting in the way of users who
would otherwise turn SELinux off. On the other hand, a targeted
policy has a "trusted" type for user logins which is explicitly
allowed access to everything.
That said, if you actually want your system to *work* with any
default-deny policy then you have to describe EVERYTHING anyways.
How exactly do you expect AppArmor to "work" if you don't allow users
to run "/bin/passwd", for example.
Cheers,
Kyle Moffett
On Sat, 9 Jun 2007 17:17:57 +0200
Andreas Gruenbacher <[email protected]> wrote:
> On Saturday 09 June 2007 10:10, Sean wrote:
> > Clinging to the current AA implementation instead of honestly considering
> > reasonable alternatives does not inspire confidence or teamwork.
>
> What you imply is pretty insulting. I can assure you we looked into many
> possible implementation choices, and we considered a fair number of
> alternatives.
Sorry for any unintended insult. The comment was meant solely for the person
with whom i was talking who seemed only to be cheerleading for inclusion
in current form without being willing or able to discuss alternative
implementations.
Sean.
On Sat, 9 Jun 2007, Kyle Moffett wrote:
> On Jun 09, 2007, at 01:18:40, [email protected] wrote:
>> SELinux is like a default allow IPS system, you have to describe EVERYTHING
>> to the system so that it knows what to allow and what to stop.
>
> WRONG. You clearly don't understand SELinux at all. Try booting in
> enforcing mode with an empty policy file (well, not quite empty, there are a
> few mandatory labels you have to create before it's a valid policy file).
> /sbin/init will load the initial policy, attempt to re-exec() itself... and
> promptly grind to a halt. End-of-story.
sigh,
two paragraphs below what you quoted I acknowledged exactly what you
state. however since you must tag everything before you turn on any
security it seems to me that you have to define everything, which is a
similar amount of work as you would have to do for a default allow policy.
> Typical "targetted" policies leave all user logins as unrestricted, adding
> security for daemons but not getting in the way of users who would otherwise
> turn SELinux off. On the other hand, a targeted policy has a "trusted" type
> for user logins which is explicitly allowed access to everything.
Ok, it sounds as if I did misunderstand SELinux. I thought that by
labeling the individual files you couldn't do the 'only restrict apache'
type of thing.
> That said, if you actually want your system to *work* with any default-deny
> policy then you have to describe EVERYTHING anyways. How exactly do you
> expect AppArmor to "work" if you don't allow users to run "/bin/passwd", for
> example.
for AA you don't try to define permissions for every executable, and ones
that you don't define policy are unrestricted.
so as I understand this with SELinux you will have lots of labels around
your system (more as you lock down the system more) you need to define
policy so that your unrestricted users must have access to every label,
and every time you create a new label you need to go back to all your
policies to see if the new label needs to be allowed from that policy
is this correct?
David Lang
On Jun 09, 2007, at 12:46:40, [email protected] wrote:
> On Sat, 9 Jun 2007, Kyle Moffett wrote:
>> Typical "targetted" policies leave all user logins as
>> unrestricted, adding security for daemons but not getting in the
>> way of users who would otherwise turn SELinux off. On the other
>> hand, a targeted policy has a "trusted" type for user logins which
>> is explicitly allowed access to everything.
>
> Ok, it sounds as if I did misunderstand SELinux. I thought that by
> labeling the individual files you couldn't do the 'only restrict
> apache' type of thing.
>
>> That said, if you actually want your system to *work* with any
>> default-deny policy then you have to describe EVERYTHING anyways.
>> How exactly do you expect AppArmor to "work" if you don't allow
>> users to run "/bin/passwd", for example.
>
> for AA you don't try to define permissions for every executable,
> and ones that you don't define policy are unrestricted.
>
> so as I understand this with SELinux you will have lots of labels
> around your system (more as you lock down the system more) you need
> to define policy so that your unrestricted users must have access
> to every label, and every time you create a new label you need to
> go back to all your policies to see if the new label needs to be
> allowed from that policy
Actually, it's easier than that. There are type attributes which may
be assigned to an arbitrary set of types, and each "type" field in an
access rule may use either a type or an attribute. So you don't
actually need to modify existing rules when adding new types, you
just add the appropriate existing attributes to your new type. For
example, you could set up a "logfile" attribute which allows
logrotate to archive old versions and allows audit-admin users to
modify/delete them, then whenever you need to add a new logfile you
just declare the "my_foo_log_t" type to have the "logfile" attribute.
On the other hand, I seem to recall that typical "targeted" policies
don't grant most of the additional access via access rules, they
instead add a special case to the fundamental "constraints" in the
policy (IE: If the subject type has the "trusted" attribute then skip
some of the other type-based checks).
Cheers,
Kyle Moffett
On Sat, 9 Jun 2007, Kyle Moffett wrote:
> On Jun 09, 2007, at 12:46:40, [email protected] wrote:
>> On Sat, 9 Jun 2007, Kyle Moffett wrote:
>> > Typical "targetted" policies leave all user logins as unrestricted,
>> > adding security for daemons but not getting in the way of users who would
>> > otherwise turn SELinux off. On the other hand, a targeted policy has a
>> > "trusted" type for user logins which is explicitly allowed access to
>> > everything.
>>
>> Ok, it sounds as if I did misunderstand SELinux. I thought that by labeling
>> the individual files you couldn't do the 'only restrict apache' type of
>> thing.
>>
>> > That said, if you actually want your system to *work* with any
>> > default-deny policy then you have to describe EVERYTHING anyways. How
>> > exactly do you expect AppArmor to "work" if you don't allow users to run
>> > "/bin/passwd", for example.
>>
>> for AA you don't try to define permissions for every executable, and ones
>> that you don't define policy are unrestricted.
>>
>> so as I understand this with SELinux you will have lots of labels around
>> your system (more as you lock down the system more) you need to define
>> policy so that your unrestricted users must have access to every label, and
>> every time you create a new label you need to go back to all your policies
>> to see if the new label needs to be allowed from that policy
>
> Actually, it's easier than that. There are type attributes which may be
> assigned to an arbitrary set of types, and each "type" field in an access
> rule may use either a type or an attribute. So you don't actually need to
> modify existing rules when adding new types, you just add the appropriate
> existing attributes to your new type. For example, you could set up a
> "logfile" attribute which allows logrotate to archive old versions and allows
> audit-admin users to modify/delete them, then whenever you need to add a new
> logfile you just declare the "my_foo_log_t" type to have the "logfile"
> attribute.
isn't this just the flip side of the same problem?
every time you define a new attribute you need to go through all the files
and decide if the new attribute needs to be given to that file.
David Lang
> On the other hand, I seem to recall that typical "targeted" policies don't
> grant most of the additional access via access rules, they instead add a
> special case to the fundamental "constraints" in the policy (IE: If the
> subject type has the "trusted" attribute then skip some of the other
> type-based checks).
>
> Cheers,
> Kyle Moffett
>
>
--- Sean <[email protected]> wrote:
> The question is: why not just extend SELinux to include AA functionality
> rather than doing a whole new subsystem.
Because, as hard as it seems for some people to believe,
not everyone wants Type Enforcement. SELinux is a fine
implementation of type enforcement, but if you don't want
what it does it would be silly to require that it be
used in order to accomplish something else, like name based
access control.
If the same things made everyone feel "secure" there would be
no optional security facilities (audit, cryptfs, /dev/random, ACLs).
It appears that the AA folks are sufficiently unimpressed with
SELinux they want to do something different. I understand that
there is a contingent that believes security == SELinux.
There are also people who believe security == cryptography or
security == virus scanners. I'm happy that they have found what
works for them.
Also, "just extend" implies that it would be easy to do. I
suggest you go read the SELinux MLS code, and go read some
of the discussions about getting MLS working for the RedHat LSP
before you go throwing "just" around.
Casey Schaufler
[email protected]
On Jun 09, 2007, at 13:32:05, [email protected] wrote:
> On Sat, 9 Jun 2007, Kyle Moffett wrote:
>> On Jun 09, 2007, at 12:46:40, [email protected] wrote:
>>> so as I understand this with SELinux you will have lots of labels
>>> around your system (more as you lock down the system more) you
>>> need to define policy so that your unrestricted users must have
>>> access to every label, and every time you create a new label you
>>> need to go back to all your policies to see if the new label
>>> needs to be allowed from that policy
>>
>> Actually, it's easier than that. There are type attributes which
>> may be assigned to an arbitrary set of types, and each "type"
>> field in an access rule may use either a type or an attribute. So
>> you don't actually need to modify existing rules when adding new
>> types, you just add the appropriate existing attributes to your
>> new type. For example, you could set up a "logfile" attribute
>> which allows logrotate to archive old versions and allows audit-
>> admin users to modify/delete them, then whenever you need to add a
>> new logfile you just declare the "my_foo_log_t" type to have the
>> "logfile" attribute.
>
> isn't this just the flip side of the same problem?
>
> every time you define a new attribute you need to go through all
> the files and decide if the new attribute needs to be given to that
> file.
No you don't, you can add attributes to a type after-the-fact. In
concept this problem is very similar to programming: You have
various documented interfaces used by different policy files to
interact with each other. As long as your policy files conform to
the documented interfaces then you *DONT* have to manually inspect
each file because you can make basic assumptions. On the other hand,
when you break that interface "contract" you will get very unexpected
results. For the above example:
My syslog policy file would create a "logfile" attribute and types
for "/var/log/auth/auth.log", "/var/log/kern/kern.log", and "/var/log/
messages". It would also create a "logdaemon" attribute which has
automatic type transitions to create files in different "/var/log/*"
directories Finally, it would allow the syslogd type to create and
append to its specific file types for "auth.log", "kern.log", and
"messages".
My logrotate policy file would depend on the syslog policy and would
declare the logrotate daemon type as a "logdaemon", and additionally
allow logrotate to read, rename, append, and delete "logfile" types.
Since logrotate is a "logdaemon", it already has the appropriate type
transitions for new types.
My samba policy file would depend on the syslog policy and would
declare the samba daemon type as a "logdaemon" and the "/var/log/
samba/*" type as a "logfile". Then it would add a type transition
rule so when "logdaemon" creates new files in "samba_log_dir_t", they
have the appropriate "samba_log_t" label. Finally, samba would allow
itself to append to "samba_log_t" files.
Note that now when "logrotate" runs and rotates files in /var/log/
samba, it will automatically create the new files with type
"samba_log_t", even though there are no *direct* associations between
those types. If the syslog policy file was poorly written it could
seriously adversely affect the security of the system, but hopefully
that's obvious :-D. Policy development is _hard_, it's a whole
separate state-machine and pseudo-programming-language that should
mostly be left to security professionals or very experienced
developers/sysadmins.
Cheers,
Kyle Moffett
On Sat, 9 Jun 2007, Kyle Moffett wrote:
> On Jun 09, 2007, at 13:32:05, [email protected] wrote:
>> On Sat, 9 Jun 2007, Kyle Moffett wrote:
>> > On Jun 09, 2007, at 12:46:40, [email protected] wrote:
>> > > so as I understand this with SELinux you will have lots of labels
>> > > around your system (more as you lock down the system more) you need to
>> > > define policy so that your unrestricted users must have access to every
>> > > label, and every time you create a new label you need to go back to all
>> > > your policies to see if the new label needs to be allowed from that
>> > > policy
>> >
>> > Actually, it's easier than that. There are type attributes which may be
>> > assigned to an arbitrary set of types, and each "type" field in an access
>> > rule may use either a type or an attribute. So you don't actually need
>> > to modify existing rules when adding new types, you just add the
>> > appropriate existing attributes to your new type. For example, you could
>> > set up a "logfile" attribute which allows logrotate to archive old
>> > versions and allows audit-admin users to modify/delete them, then
>> > whenever you need to add a new logfile you just declare the
>> > "my_foo_log_t" type to have the "logfile" attribute.
>>
>> isn't this just the flip side of the same problem?
>>
>> every time you define a new attribute you need to go through all the files
>> and decide if the new attribute needs to be given to that file.
>
> No you don't, you can add attributes to a type after-the-fact. In concept
> this problem is very similar to programming: You have various documented
> interfaces used by different policy files to interact with each other. As
> long as your policy files conform to the documented interfaces then you
> *DONT* have to manually inspect each file because you can make basic
> assumptions. On the other hand, when you break that interface "contract" you
> will get very unexpected results. For the above example:
>
> My syslog policy file would create a "logfile" attribute and types for
> "/var/log/auth/auth.log", "/var/log/kern/kern.log", and "/var/log/messages".
> It would also create a "logdaemon" attribute which has automatic type
> transitions to create files in different "/var/log/*" directories Finally,
> it would allow the syslogd type to create and append to its specific file
> types for "auth.log", "kern.log", and "messages".
>
> My logrotate policy file would depend on the syslog policy and would declare
> the logrotate daemon type as a "logdaemon", and additionally allow logrotate
> to read, rename, append, and delete "logfile" types. Since logrotate is a
> "logdaemon", it already has the appropriate type transitions for new types.
>
> My samba policy file would depend on the syslog policy and would declare the
> samba daemon type as a "logdaemon" and the "/var/log/samba/*" type as a
> "logfile". Then it would add a type transition rule so when "logdaemon"
> creates new files in "samba_log_dir_t", they have the appropriate
> "samba_log_t" label. Finally, samba would allow itself to append to
> "samba_log_t" files.
if you have your policy figured out and then go and apply it to
applications then you are correct.
I'm talking about the situation where you start off by defining a policy
for Samba, and then afterwords decide that you want to have seperate
"logfile" and "logdaemon" type then you would need to go back and
re-examine all the files to tell what needs to be labeled as what.
if you can do all the policy design in advance (and get it right) then
SELinux is a great solution. if you don't have that time and have to do
the policy incrementaly you will end up revisiting and revising your
entire policy each time you go to add something.
> Note that now when "logrotate" runs and rotates files in /var/log/samba, it
> will automatically create the new files with type "samba_log_t", even though
> there are no *direct* associations between those types. If the syslog policy
> file was poorly written it could seriously adversely affect the security of
> the system, but hopefully that's obvious :-D. Policy development is _hard_,
> it's a whole separate state-machine and pseudo-programming-language that
> should mostly be left to security professionals or very experienced
> developers/sysadmins.
I _am_ a security professional. I've been doing security sysadmin work on
Linux for over a decade now. From your description I'm exactly the type of
person you are saying should be figuring this out. So please back off of
the 'this is hard, you should leave it to the professionals' line a
little bit ;-)
if the AA policies can be compiled into SELinux policies that would work
(currently they can't and many SELinux people oppose the features that
would need to be added to make it possible) but the compile process leaves
room for more bugs in an areas that's going to be hard to investigate.
(This isn't a fault of SELinux, it's a common issue with compilers, the
compiled 'thing' is designed to be machine friendly, not user friendly. it
doesn't matte if it's compiling C into machine code or high-level firewall
rules into iptables commands or AA policies into SELinux labels and
policies). adding a complex intermediate layer does not nessasarily add
security, but it definantly adds complication.
once SELinux has a way for a trusted user to edit a security sensitive
file (via the process of creating a file and renameing it into place)
without needing SELinux aware tools and have the result accepted as valid
by the rest of the system then it becomes possible to implement an AA to
SELinux policy compiler, but saying that AA should not be accepted becouse
it's possible to modify SELinux and write such a compile with sufficant
effort is not reasonable. While there are many cases where multiple ways
of doing something are not allowed into the kernel (suspend/hibernate is
an example) there are also cases where multiple ways of doing things are
allowed, and the LSM hooks are in place explicitly to permit different
types of security modules to use them.
David Lang
Hi!
> > > I assume you mean labels instead of handles.
> > >
> > > AppArmor's design is around paths not labels, and independent of whether or
> > > not you like AppArmor, this design leads to a useful security model distinct
> > > from the SELinux security model (which is useful in its own ways). The
> > > differences between those models cannot be argued away, neither is a subset
> > > of the other, and neither is a misdesign. I would be thankful if you could
> > > stop spreading this lie.
> >
> > I have a hard time distinguishing AppArmor's "model" from its
> > implementation; every time we suggest that one might emulate much of
> > AppArmor's functionality on SELinux (as in SEEdit), someone points to a
> > specific characteristic of the AppArmor implementation that cannot be
> > emulated in this manner. But is that implementation characteristic an
> > actual requirement or just how it happens to have been done to date in
> > AA? And I get the impression that even if we extended SELinux in
> > certain ways to ease such emulation, the AA folks would never be
> > satisfied because the implementation would still differ. Can we
> > separate the desired functionality and actual requirements from the
> > implementation specifics?
>
> That's a really good point, is there a description of the AA "model"
> anywhere that we could see to determine if there really is a way to
> possibly use the current SELinux internals to show this model to the
> user?
Hmm, techdoc.pdf (attached) is supposed to describe this "model", but
it is more of "AA works like this" with no explanations.... and
includes (probably unwanted) quirks like various races during path
resolution.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> >So, AA developers, do you have such a document anywhere? I know there
> >are some old research papers, do they properly describe the current
> >model you are trying to implement here?
>
> Greg,
> to implement the AA approach useing SELinux you need to have a way that
> files that are renamed or created get tagged with the right label
> automaticaly with no possible race condition.
>
> If this can be done then it _may_ be possible to do the job that AA is
> aimed at with SELinux, but the work nessasary to figure out what lables
> are needed on what file would still make it a non-trivial task.
>
> as I understand it SELinux puts one label on each file, so if you have
> three files accessed by two programs such that
> program A accesses files X Y
> program B accesses files Y Z
>
> then files X Y and Z all need seperate labels with the policy stateing
> that program A need to access labels X, Y and program B needs to access
> files Y Z
>
> extended out this can come close to giving each file it's own label. AA
> essentially does this and calls the label the path and computes it at
> runtime instead of storing it somewhere.
Yes, and in the process, AA stores compiled regular expressions in
kernel. Ouch. I'll take "each file it's own label" over _that_ any time.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun, 10 Jun 2007, Pavel Machek wrote:
> Hi!
>
>>> So, AA developers, do you have such a document anywhere? I know there
>>> are some old research papers, do they properly describe the current
>>> model you are trying to implement here?
>>
>> Greg,
>> to implement the AA approach useing SELinux you need to have a way that
>> files that are renamed or created get tagged with the right label
>> automaticaly with no possible race condition.
>>
>> If this can be done then it _may_ be possible to do the job that AA is
>> aimed at with SELinux, but the work nessasary to figure out what lables
>> are needed on what file would still make it a non-trivial task.
>>
>> as I understand it SELinux puts one label on each file, so if you have
>> three files accessed by two programs such that
>> program A accesses files X Y
>> program B accesses files Y Z
>>
>> then files X Y and Z all need seperate labels with the policy stateing
>> that program A need to access labels X, Y and program B needs to access
>> files Y Z
>>
>> extended out this can come close to giving each file it's own label. AA
>> essentially does this and calls the label the path and computes it at
>> runtime instead of storing it somewhere.
>
> Yes, and in the process, AA stores compiled regular expressions in
> kernel. Ouch. I'll take "each file it's own label" over _that_ any time.
and if each file has it's own label you are going to need regex or similar
to deal with them as well.
David Lang
Andreas Gruenbacher wrote:
> On Saturday 09 June 2007 02:17, Greg KH wrote:
>
>> On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
>>
>>> AppArmor is meant to be relatively easy to understand, manage, and
>>> customize, and introducing a labels layer wouldn't help these goals.
>>>
>> Woah, that describes the userspace side of AA just fine, it means
>> nothing when it comes to the in-kernel implementation. There is no
>> reason that you can't implement the same functionality using some
>> totally different in-kernel solution if possible.
>>
> I agree that the in-kernel implementation could use different abstractions
> than user-space, provided that the underlying implementation details can be
> hidden well enough. The key phrase here is "if possible", and in fact "if
> possible" is much too strong: very many things in software are possible,
> including user-space drives and a stable kernel module ABI. Some things make
> sense; others are genuinely bad ideas while still possible.
>
In particular, to layer AppArmor on top of SELinux, the following
problems must be addressed:
* New files: when a file is created, it is labeled according to the
type of the creating process and the type of the parent directory.
Applications can also use libselinux to use application logic to
relabel the file, but that is not 'mandatory' policy, and fails in
cases like cp and mv. AppArmor lets you create a policy that e..g
says "/home/*/.plan r" to permit fingerd to read everyone's .plan
file, should it ever exist, and you cannot emulate that with SELinux.
* Renamed Files: Renaming a file changes the policy with respect to
that file in AA. To emulate this in SELinux, you would have to
have a way to instantly re-label the file upon rename.
* Renamed Directory trees: The above problem is compounded with
directory trees. Changing the name at the top of a large, bushy
tree can require instant relabeling of millions of files.
* New Policies: The SEEdit approach of compiling AA profiles into
SELinux labels involves computing the partition set of files, so
that each element of the partition set is unique, and corresponds
to all the policies that treat every file in the element
identically. If you create a new profile that touches *some* of
the files in such an element, then you have to split that
synthetic label, re-compute the partition set, and re-label the
file system.
* File Systems That Do Not Support Labels: The most important being
NFS3 and FAT. Because they do not support labels at all, SELinux
has to give you an all-or-nothing access control on the entire
remote volume. AA can give you nuanced access control in these
file systems.
You could support all of these features in SELinux, but only by adding
an in-kernel file matching mechanism similar to AppArmor. It would
basically load an AppArmor policy into the kernel, label files as they
are brought from disk into the cache, and then use SELinux to do the
access controls.
That doesn't make it a good idea:
* The patch would be at least as complex and intrusive as the
proposed AppArmor patch, there is no simplicity already-upstream
savings here.
* It would require the VFS and d_path patches that AppArmor needs to
pass mount points down.
* It would make AppArmor's ability to change policies on a live
system more difficult.
* The necessary extensions would not be appealing to the SELinux
community.
LSM is the common code that AA and SELinux have agreed to be mutually
useful. Forcing AA to sit on top of SELinux would harm both AA and SELinux.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor
--- [email protected] wrote:
> > Yes, and in the process, AA stores compiled regular expressions in
> > kernel. Ouch. I'll take "each file it's own label" over _that_ any time.
>
> and if each file has it's own label you are going to need regex or similar
> to deal with them as well.
Now that you're going to have to explain. Nothing like that
on any of the MLS systems I'm familiar with, and I think that
I know just about all of them.
Casey Schaufler
[email protected]
Casey Schaufler wrote:
> --- [email protected] wrote:
>
>>> Yes, and in the process, AA stores compiled regular expressions in
>>> kernel. Ouch. I'll take "each file it's own label" over _that_ any time.
>>>
>> and if each file has it's own label you are going to need regex or similar
>> to deal with them as well.
>>
> Now that you're going to have to explain. Nothing like that
> on any of the MLS systems I'm familiar with, and I think that
> I know just about all of them.
>
I suspect that David meant that if you were using "unique label per
file" as an implementation technique to implement AA on top of SELinux,
that you would then need a regexp to discern labels.
It's hard to recall with all the noise, but at this point in the thread
the discussion is about the best way to implement AA. Some have alleged
that AA layered on top of SELinux is the best way. I think that is
clearly wrong; AA layered on top of SELinux is possible, but would
require a bunch of enhancements to SELinux first, and the result would
be more complex than the proposed AA patch and have weaker functionality
and performance.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor
[email protected] wrote:
> On Fri, 8 Jun 2007, Greg KH wrote:
>> I still want to see a definition of the AA "model" that we can then use
>> to try to implement using whatever solution works best. As that seems
>> to be missing the current argument of if AA can or can not be
>> implemented using SELinux or something totally different should be
>> stopped.
> the way I would describe the difference betwen AA and SELinux is:
>
> SELinux is like a default allow IPS system, you have to describe
> EVERYTHING to the system so that it knows what to allow and what to stop.
>
> AA is like a default deny firewall, you describe what you want to
> happen, and it blocks everything else without you even having to
> realize that it's there.
That's not quite right:
* SELinux Strict Policy is a default-deny system: it specifies
everything that is permitted system wide, and all else is denied.
* AA and the SELinux Targeted Policy are hybrid systems:
o default-deny within a policy or profile: confined processes
are only permitted to do what the policy says, and all else
is denied.
o default-allow system wide: unconfined processes are allowed
to do anything that classic DAC permissions allow.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor
Hi!
> >>extended out this can come close to giving each file it's own label. AA
> >>essentially does this and calls the label the path and computes it at
> >>runtime instead of storing it somewhere.
> >
> >Yes, and in the process, AA stores compiled regular expressions in
> >kernel. Ouch. I'll take "each file it's own label" over _that_ any time.
>
> and if each file has it's own label you are going to need regex or similar
> to deal with them as well.
But you have that regex in _user_ space, in a place where policy
is loaded into kernel.
AA has regex parser in _kernel_ space, which is very wrong.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Crispin Cowan wrote:
> [email protected] wrote:
>
>> On Fri, 8 Jun 2007, Greg KH wrote:
>>
>>> I still want to see a definition of the AA "model" that we can then use
>>> to try to implement using whatever solution works best. As that seems
>>> to be missing the current argument of if AA can or can not be
>>> implemented using SELinux or something totally different should be
>>> stopped.
>>>
>> the way I would describe the difference betwen AA and SELinux is:
>>
>> SELinux is like a default allow IPS system, you have to describe
>> EVERYTHING to the system so that it knows what to allow and what to stop.
>>
>> AA is like a default deny firewall, you describe what you want to
>> happen, and it blocks everything else without you even having to
>> realize that it's there.
>>
> That's not quite right:
>
> * SELinux Strict Policy is a default-deny system: it specifies
> everything that is permitted system wide, and all else is denied.
> * AA and the SELinux Targeted Policy are hybrid systems:
> o default-deny within a policy or profile: confined processes
> are only permitted to do what the policy says, and all else
> is denied.
> o default-allow system wide: unconfined processes are allowed
> to do anything that classic DAC permissions allow.
>
Still not completely correct, though the targeted policy has an
unconfined domain (unconfined_t) the policy still has allow rules for
everything unconfined can do, 2 examples of things unconfined still
can't do (because they aren't allowed by the targeted policy) is execmem
and a while back when there was a /proc exploit that required setattr on
/proc/self/environ; unconfined_t wasn't able to do that either (and
therefore the exploit didn't work on a targeted system).
That said, the differentiation between strict and targeted is going away
soon so that one can have some users be unconfined (but still with a few
restrictions) and others can be fully restricted.
On Sun, 10 Jun 2007, Pavel Machek wrote:
>>>> extended out this can come close to giving each file it's own label. AA
>>>> essentially does this and calls the label the path and computes it at
>>>> runtime instead of storing it somewhere.
>>>
>>> Yes, and in the process, AA stores compiled regular expressions in
>>> kernel. Ouch. I'll take "each file it's own label" over _that_ any time.
>>
>> and if each file has it's own label you are going to need regex or similar
>> to deal with them as well.
>
> But you have that regex in _user_ space, in a place where policy
> is loaded into kernel.
then the kernel is going to have to call out to userspace every time a
file is created or renamed and the policy is going to be enforced
incorrectly until userspace finished labeling/relabeling whatever is
moved. building this sort of race condigion for security into the kernel
is highly questionable at best.
> AA has regex parser in _kernel_ space, which is very wrong.
see Linus' rants about why it's not automaticaly the best thing to move
functionality into userspace.
remember that the files covered by an AA policy can change as files are
renamed. this isn't the case with SELinux so it doesn't have this sort of
problem.
David Lang
On Sun, 10 Jun 2007, Crispin Cowan wrote:
> Casey Schaufler wrote:
>> --- [email protected] wrote:
>>
>>>> Yes, and in the process, AA stores compiled regular expressions in
>>>> kernel. Ouch. I'll take "each file it's own label" over _that_ any time.
>>>>
>>> and if each file has it's own label you are going to need regex or similar
>>> to deal with them as well.
>>>
>> Now that you're going to have to explain. Nothing like that
>> on any of the MLS systems I'm familiar with, and I think that
>> I know just about all of them.
>>
> I suspect that David meant that if you were using "unique label per
> file" as an implementation technique to implement AA on top of SELinux,
> that you would then need a regexp to discern labels.
exactly.
say that we give each file a unique label, and for simplicity we set the
label == path (note that this raises the issue, what will SELinux do when
there are multiple paths to the same file)
now say that you want to grant apache access to all files that have labels
that follow the pattern '/home/*/http/* ?
you are either going to use regex matching, or you are going to have to
enumerate every label that matches this (potentially a very large list).
and if you try to generate the enumerated list you need to add a label to
the list if a file is renamed or created to match the pattern, and delete
a file from the list if it is renamed to no longer match the pattern
> It's hard to recall with all the noise, but at this point in the thread
> the discussion is about the best way to implement AA. Some have alleged
> that AA layered on top of SELinux is the best way. I think that is
> clearly wrong; AA layered on top of SELinux is possible, but would
> require a bunch of enhancements to SELinux first, and the result would
> be more complex than the proposed AA patch and have weaker functionality
> and performance.
AA as-is needs to figure out how to deal with bind-mounts, and how to
handle hardlink creation in a more ganular manner (and potentially other
resources like network sockets), but it's useful now even without these
improvements
AA over SELinux would need for SELinux to figure out how to handle file
creation, file renames, and multiple paths for the same file (hard-links
and bind-mounts). In addition a userspace daemon would have to be written
to re-label files and/or change policy on the fly as files are renamed.
the result would still have race conditions due to the need to re-label
large numbers of files
ACPI should have taught everyone that sometimes putting an interpreter in
the kernel really is the best option. looking at the problems of bouncing
back out to userspace for file creation and renames it looks like a regex
in the kernel is a lot safer and more reliable.
David Lang
On Sun, 10 Jun 2007 23:45:16 -0700 (PDT)
[email protected] wrote:
> say that we give each file a unique label, and for simplicity we set the
> label == path (note that this raises the issue, what will SELinux do when
> there are multiple paths to the same file)
So don't do that then.
> now say that you want to grant apache access to all files that have labels
> that follow the pattern '/home/*/http/* ?
>
> you are either going to use regex matching, or you are going to have to
> enumerate every label that matches this (potentially a very large list).
> and if you try to generate the enumerated list you need to add a label to
> the list if a file is renamed or created to match the pattern, and delete
> a file from the list if it is renamed to no longer match the pattern
If AA requires regex matching in the kernel, perhaps it really isn't
appropriate for inclusion. Surely there has to be a better way than
requiring the kernel to do regex matches at runtime?
> AA over SELinux would need for SELinux to figure out how to handle file
> creation, file renames, and multiple paths for the same file (hard-links
> and bind-mounts). In addition a userspace daemon would have to be written
> to re-label files and/or change policy on the fly as files are renamed.
> the result would still have race conditions due to the need to re-label
> large numbers of files
WRONG. The labels would be obtained from AA as needed, never recorded in
the file attributes. This would change nothing about what AA needed
to compute at runtime, just the way it implements the result.
> ACPI should have taught everyone that sometimes putting an interpreter in
> the kernel really is the best option. looking at the problems of bouncing
> back out to userspace for file creation and renames it looks like a regex
> in the kernel is a lot safer and more reliable.
There hasn't yet been shown a requirement for a userspace daemon to implement
AA over SeLinux.
Sean
On Mon, 11 Jun 2007, Sean wrote:
> [email protected] wrote:
>
>> say that we give each file a unique label, and for simplicity we set the
>> label == path (note that this raises the issue, what will SELinux do when
>> there are multiple paths to the same file)
>
> So don't do that then.
>
>> now say that you want to grant apache access to all files that have labels
>> that follow the pattern '/home/*/http/* ?
>>
>> you are either going to use regex matching, or you are going to have to
>> enumerate every label that matches this (potentially a very large list).
>> and if you try to generate the enumerated list you need to add a label to
>> the list if a file is renamed or created to match the pattern, and delete
>> a file from the list if it is renamed to no longer match the pattern
>
> If AA requires regex matching in the kernel, perhaps it really isn't
> appropriate for inclusion. Surely there has to be a better way than
> requiring the kernel to do regex matches at runtime?
>
>> AA over SELinux would need for SELinux to figure out how to handle file
>> creation, file renames, and multiple paths for the same file (hard-links
>> and bind-mounts). In addition a userspace daemon would have to be written
>> to re-label files and/or change policy on the fly as files are renamed.
>> the result would still have race conditions due to the need to re-label
>> large numbers of files
>
> WRONG. The labels would be obtained from AA as needed, never recorded in
> the file attributes. This would change nothing about what AA needed
> to compute at runtime, just the way it implements the result.
Ok, you are proposing throwing out all the label handling that SELinux
does, including any caching. forgive me if I agree with the SELinux people
that this is a very bad idea.
>> ACPI should have taught everyone that sometimes putting an interpreter in
>> the kernel really is the best option. looking at the problems of bouncing
>> back out to userspace for file creation and renames it looks like a regex
>> in the kernel is a lot safer and more reliable.
>
> There hasn't yet been shown a requirement for a userspace daemon to implement
> AA over SeLinux.
I thought the userspace component was what you were proposing instead of
doing the regex matching in the kernel. if this isn't it what exactly are
you proposing?
you don't want the regex matching in the kernel.
you don't want a userspace component to do the regex matching when files
are created or renamed.
how exactly do you propose to figure out what should happen to a file when
it is created or it (or a parent directory) is renamed?
AA policies are defined in terms of regex expressions. you say that this
should be able to be done on top of SELinux somehow without changing the
policies. so somewhere, something needs to interpret the regex to see if
it matches the path. this needs to be either kernel code or userspace
code. you have ruled out kernel code and are now claiming that userspace
isn't needed.
David Lang
Hi!
> ACPI should have taught everyone that sometimes putting an interpreter in
> the kernel really is the best option. looking at the problems of bouncing
> back out to userspace for file creation and renames it looks like a regex
> in the kernel is a lot safer and more reliable.
What do ACPI and AA have in common?
* they both start with A
* there are both nightmare
* they both put interpretter into kernel
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 11 Jun 2007 02:33:30 -0700 (PDT)
[email protected] wrote:
> Ok, you are proposing throwing out all the label handling that SELinux
> does, including any caching. forgive me if I agree with the SELinux people
> that this is a very bad idea.
Well presumably AA would be doing caching etc.. so that doesn't seem like
a problem. The SELinux people seem to think that accepting AA into the
kernel and supporting path based security at all is a mistake. I guess
I forgive you for agreeing with them ;)
> I thought the userspace component was what you were proposing instead of
> doing the regex matching in the kernel. if this isn't it what exactly are
> you proposing?
No.. i've said quite a few times now that i'm not talking about calling out
to userspace. The entire discussion of regex matching is a completely
separate discussion. It's either the right thing to do, or not. But the
same issues in regard to regex matching apply whether AA is built on top
of SELinux or not.
> AA policies are defined in terms of regex expressions. you say that this
> should be able to be done on top of SELinux somehow without changing the
> policies. so somewhere, something needs to interpret the regex to see if
> it matches the path. this needs to be either kernel code or userspace
> code. you have ruled out kernel code and are now claiming that userspace
> isn't needed.
For whatever it's worth, i'll repeat again. The AA kernel extension would
be associating paths with labels (using regex, or not). At that point all
policy decisions would be enforced by SELinux using standard SELinux policy
rules. The SELinux policy would be a translated version of the AA policy
file. The translation could of course happen in userland.
The net affect of all that... is that you get a version of SELinux which
can be configured with the user friendly AA policy file format. And,
files won't need to carry around security labels with them. I leave
the debate about whether that's a good idea in general to others. But
from what i can tell, it's the only significant difference between
SELinux and AA.
Depending on the way it was implemented, its conceivable that users could
mix and match native SELinux policy with custom AA policies as they
saw fit.
Sean
On Sat, 2007-06-09 at 00:03 +0200, Andreas Gruenbacher wrote:
> On Wednesday 06 June 2007 15:26, Stephen Smalley wrote:
> > - under AA, each file may have an arbitrary set of "labels" or
> > "policies" applied to it depending on what programs are accessing it and
> > what names are being used to reference it - there is no system view of
> > the subjects and objects and thus no way to identify the overall system
> > policy for a given file.
>
> Look at it this way: under SELinux, the set of files that share a label forms
> an equivalence class -- they are all treated identically by the system's
> security policy. The rules in AppArmor profiles also define equivalence
> classes in the sense that they partition the filesystem namespace into sets
> of files that are treated identically, but this classification is not
> explicit -- the entire rule base contributes to the classification. This
> doesn't mean that there is not a global policy, just that the policy is
> modeled differently. The equivalence classes are not directly obvious from
> the AA profiles.
No, it really does mean that there is no global policy, and it goes
beyond "not directly obvious" to "can not be determined" from the AA
profiles. You can't compose the set of AA profiles and say anything
useful, because they are written in terms of ambiguous and unstable
identifiers. /a/b/c may refer to completely different objects in two
different profiles, or to the same object as /d/e/f in the same or
another profile.
> Contrast this with SEEdit, which compiles AA-style rules into labels (and thus
> equivalence classes). The resulting SELinux policy is a static snapshot that
> cannot easily accommodate rule base changes, is more limited with respect to
> new files (which would likely be fixable), and behaves differently in complex
> ways with file renames. What's more, most likely the compiled policy will be
> anywhere from very hard to impossible to analyze, so you pretty much lose on
> all ends.
Just to clarify, you can change the allowed accesses from a given
subject to a given object without relabeling, just by changing the
policy allow rules; you only have to relabel the object in the case
where you want to distinguish that object from another object with the
same label for the same subject. I think the new file situation could
be improved without any major change to the SELinux model, and am not
opposed to leveraging the component name there, as previously noted. On
the file rename case, I think we have it right - access rights shouldn't
change automatically when a file is renamed, any more than DAC ownership
or file modes should.
> > - names are far less tranquil than labels.
>
> If I'm getting things right, a tranquil system with respect to labels would be
> one that does not permit re-labeling, while a tranquil system with respect to
> path names would be one that does not permit renaming. Both approaches would
> buy greater analyzability with reduced usability, and both seem unrealistic
> to me. SELinux and AppArmor evidently have different goals, and tranquility
> is more important to SELinux.
Tranquility is important to correctness and understandability of policy;
if labels (or pathnames in your case) can change at any time, then you
have the problems of revocation of access (impractical to completely
implement in Linux) and your effective policy now varies over time, so
you have to consider time as a factor in your policy analysis.
> AppArmor is meant to be relatively easy to understand, manage, and customize,
> and introducing a labels layer wouldn't help these goals. SELinux is
> applicable in areas where AppArmor is not (e.g., MLS), but this comes at a
> cost. For me the question is not SELinux or AppArmor, but if AppArmor's
> security model is a good solution in common scenarios. In my opinion,
> AppArmor is a better answer than SELinux in a number of scenarios. This gives
> it value, nonwithstanding the fact that SELinux can be taken further.
I'd agree that we shouldn't try to emulate AA as it is on SELinux. The
question is more of whether we can meet the higher level functionality
goals that make some people want to use AA via SELinux. That requires
separating those goals from the implementation details of AA.
--
Stephen Smalley
National Security Agency
On 2007-06-10T23:05:47, Pavel Machek <[email protected]> wrote:
> But you have that regex in _user_ space, in a place where policy
> is loaded into kernel.
>
> AA has regex parser in _kernel_ space, which is very wrong.
That regex parser only applies user defined policy. The logical
connection between your two points doesn't exist.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
[email protected] wrote:
> On Sun, 10 Jun 2007, Pavel Machek wrote:
>> But you have that regex in _user_ space, in a place where policy
>> is loaded into kernel.
>
> then the kernel is going to have to call out to userspace every time a
> file is created or renamed and the policy is going to be enforced
> incorrectly until userspace finished labeling/relabeling whatever is
> moved. building this sort of race condigion for security into the kernel
> is highly questionable at best.
>
>> AA has regex parser in _kernel_ space, which is very wrong.
>
> see Linus' rants about why it's not automaticaly the best thing to move
> functionality into userspace.
>
> remember that the files covered by an AA policy can change as files are
> renamed. this isn't the case with SELinux so it doesn't have this sort
> of problem.
How about using the inotify interface on / to watch for file changes and
updating the SELinux policies on the fly. This could be done from a
userspace daemon and should require minimal SELinux changes.
The only possible problems I can see are the (hopefully) small gap
between the file change and updating the policy and the performance
problems of watching the whole system for changes.
Just my $0.02.
Jack
On Thu, 14 Jun 2007, Jack Stone wrote:
> [email protected] wrote:
>> On Sun, 10 Jun 2007, Pavel Machek wrote:
>>> But you have that regex in _user_ space, in a place where policy
>>> is loaded into kernel.
>>
>> then the kernel is going to have to call out to userspace every time a
>> file is created or renamed and the policy is going to be enforced
>> incorrectly until userspace finished labeling/relabeling whatever is
>> moved. building this sort of race condigion for security into the kernel
>> is highly questionable at best.
>>
>>> AA has regex parser in _kernel_ space, which is very wrong.
>>
>> see Linus' rants about why it's not automaticaly the best thing to move
>> functionality into userspace.
>>
>> remember that the files covered by an AA policy can change as files are
>> renamed. this isn't the case with SELinux so it doesn't have this sort
>> of problem.
>
> How about using the inotify interface on / to watch for file changes and
> updating the SELinux policies on the fly. This could be done from a
> userspace daemon and should require minimal SELinux changes.
>
> The only possible problems I can see are the (hopefully) small gap
> between the file change and updating the policy and the performance
> problems of watching the whole system for changes.
as was mentioned by someone else, if you rename a directory this can
result in millions of files that need to be relabeled (or otherwise have
the policy changed for them)
that can take a significant amount of time to do.
David Lang
Hi!
> I also don't care about the details of how it gets
> implemented, but when the AA people have a working
> implementation, and the SELinux people are strongly
> opposed to the concept, I don't see any advantage in
Actually, SELinux people 'liked' the concept -- they are willing to
extend SELinux to handle new files better. And not only SELinux people
are opposed to AA.
> if the SELinux people had responded to the announcement
> of AA with "that's a nice idea, if we add these snippits
> from your code to SELinux then we can do the same thing"
> it would be a very different story.
It was something like 'is there description of AA security model? We'd
like to take a look if we can do that within SELinux'. I tried to
forward them pdf, but it was more AA implementation description (not
AA model description) so it was probably not helpful.
So yes, SELinux people want to help.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu, Jun 14, 2007 at 05:18:43PM -0700, [email protected] wrote:
> On Thu, 14 Jun 2007, Jack Stone wrote:
>
> > [email protected] wrote:
> >> On Sun, 10 Jun 2007, Pavel Machek wrote:
> >>> But you have that regex in _user_ space, in a place where policy
> >>> is loaded into kernel.
> >>
> >> then the kernel is going to have to call out to userspace every time a
> >> file is created or renamed and the policy is going to be enforced
> >> incorrectly until userspace finished labeling/relabeling whatever is
> >> moved. building this sort of race condigion for security into the kernel
> >> is highly questionable at best.
> >>
> >>> AA has regex parser in _kernel_ space, which is very wrong.
> >>
> >> see Linus' rants about why it's not automaticaly the best thing to move
> >> functionality into userspace.
> >>
> >> remember that the files covered by an AA policy can change as files are
> >> renamed. this isn't the case with SELinux so it doesn't have this sort
> >> of problem.
> >
> > How about using the inotify interface on / to watch for file changes and
> > updating the SELinux policies on the fly. This could be done from a
> > userspace daemon and should require minimal SELinux changes.
> >
> > The only possible problems I can see are the (hopefully) small gap
> > between the file change and updating the policy and the performance
> > problems of watching the whole system for changes.
>
> as was mentioned by someone else, if you rename a directory this can result
> in millions of files that need to be relabeled (or otherwise have the policy
> changed for them)
>
> that can take a significant amount of time to do.
So? The number of "real-world" times that this happens is probably
non-existant on a "production" server. And if you are doing this on a
developer machine, then yes, there might be some slow-down, but no more
than is currently happening with tools like Beagle that people are
already shipping and supporting in "enterprise" solutions.
thanks,
greg k-h
On Sun, Jun 10, 2007 at 10:09:18AM -0700, Crispin Cowan wrote:
> Andreas Gruenbacher wrote:
> > On Saturday 09 June 2007 02:17, Greg KH wrote:
> >
> >> On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
> >>
> >>> AppArmor is meant to be relatively easy to understand, manage, and
> >>> customize, and introducing a labels layer wouldn't help these goals.
> >>>
> >> Woah, that describes the userspace side of AA just fine, it means
> >> nothing when it comes to the in-kernel implementation. There is no
> >> reason that you can't implement the same functionality using some
> >> totally different in-kernel solution if possible.
> >>
> > I agree that the in-kernel implementation could use different abstractions
> > than user-space, provided that the underlying implementation details can be
> > hidden well enough. The key phrase here is "if possible", and in fact "if
> > possible" is much too strong: very many things in software are possible,
> > including user-space drives and a stable kernel module ABI. Some things make
> > sense; others are genuinely bad ideas while still possible.
> >
> In particular, to layer AppArmor on top of SELinux, the following
> problems must be addressed:
>
> * New files: when a file is created, it is labeled according to the
> type of the creating process and the type of the parent directory.
> Applications can also use libselinux to use application logic to
> relabel the file, but that is not 'mandatory' policy, and fails in
> cases like cp and mv. AppArmor lets you create a policy that e..g
> says "/home/*/.plan r" to permit fingerd to read everyone's .plan
> file, should it ever exist, and you cannot emulate that with SELinux.
A daemon using inotify can "instantly"[1] detect this and label the file
properly if it shows up.
> * Renamed Files: Renaming a file changes the policy with respect to
> that file in AA. To emulate this in SELinux, you would have to
> have a way to instantly re-label the file upon rename.
Same daemon can do the re-label.
> * Renamed Directory trees: The above problem is compounded with
> directory trees. Changing the name at the top of a large, bushy
> tree can require instant relabeling of millions of files.
Same daemon can do this. And yes, it might take a ammount of time, but
the times that this happens in "real-life" on a "production" server is
quite small, if at all.
> * New Policies: The SEEdit approach of compiling AA profiles into
> SELinux labels involves computing the partition set of files, so
> that each element of the partition set is unique, and corresponds
> to all the policies that treat every file in the element
> identically. If you create a new profile that touches *some* of
> the files in such an element, then you have to split that
> synthetic label, re-compute the partition set, and re-label the
> file system.
Again, same daemon can handle this logic.
> * File Systems That Do Not Support Labels: The most important being
> NFS3 and FAT. Because they do not support labels at all, SELinux
> has to give you an all-or-nothing access control on the entire
> remote volume. AA can give you nuanced access control in these
> file systems.
SELinux already provides support for the whole mounted filesystem,
which, in real-life testing, seems to be quite sufficient. Also, the
SELinux developers are working on some changes to make this a bit more
fine-grained.
See also Stephan's previous comments about NFSv3 client directories and
multiple views having the potential to cause a lot of havoc.
> You could support all of these features in SELinux, but only by adding
> an in-kernel file matching mechanism similar to AppArmor.
I don't think that is necessary at all, see above for why.
> It would basically load an AppArmor policy into the kernel, label
> files as they are brought from disk into the cache, and then use
> SELinux to do the access controls.
No, do the labeling in userspace with a daemon using inotify to handle
the changing of the files around.
Or has this whole idea of a daemon been disproved already with a
prototype somewhere that failed? If not, a simple test app would not be
that hard to hack up. Maybe I'll see if I can do it during the week of
June 24 :)
thanks,
greg k-h
--- Greg KH <[email protected]> wrote:
> A daemon using inotify can "instantly"[1] detect this and label the file
> properly if it shows up.
In our 1995 B1 evaluation of Trusted Irix we were told in no
uncertain terms that such a solution was not acceptable under
the TCSEC requirements. Detection and relabel on an unlocked
object creates an obvious window for exploitation. We were told
that such a scheme would be considered a design flaw.
I understand that some of the Common Criteria labs are less
aggressive regarding chasing down these issues than the NCSC
teams were. It might not prevent an evaluation from completing
today. It is still hard to explain why it's ok to have a file
that's labeled incorrectly _even briefly_. It is the systems
job to ensure that that does not happen.
Casey Schaufler
[email protected]
On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote:
> --- Greg KH <[email protected]> wrote:
>
>
> > A daemon using inotify can "instantly"[1] detect this and label the file
> > properly if it shows up.
>
> In our 1995 B1 evaluation of Trusted Irix we were told in no
> uncertain terms that such a solution was not acceptable under
> the TCSEC requirements. Detection and relabel on an unlocked
> object creates an obvious window for exploitation. We were told
> that such a scheme would be considered a design flaw.
>
> I understand that some of the Common Criteria labs are less
> aggressive regarding chasing down these issues than the NCSC
> teams were. It might not prevent an evaluation from completing
> today. It is still hard to explain why it's ok to have a file
> that's labeled incorrectly _even briefly_. It is the systems
> job to ensure that that does not happen.
Um, Casey, he is talking about how to emulate AppArmor behavior on a
label-based system like SELinux, not meeting B1 or LSPP or anything like
that (which AppArmor can't do regardless). As far as general issue
goes, if your policy is configured such that the new file gets the most
restrictive label possible at creation time and then the daemon relabels
it to a less restrictive label if appropriate, then there is no actual
window of exposure.
Also, there is such a daemon, restorecond, in SELinux (policycoreutils)
although we avoid relying on it for anything security-critical
naturally. And one could introduce the named type transition concept
that has been discussed in this thread without much difficulty to
selinux.
--
Stephen Smalley
National Security Agency
Hi!
And before you scream "races", take a look. It does not actually add
them:
> > > I agree that the in-kernel implementation could use different abstractions
> > > than user-space, provided that the underlying implementation details can be
> > > hidden well enough. The key phrase here is "if possible", and in fact "if
> > > possible" is much too strong: very many things in software are possible,
> > > including user-space drives and a stable kernel module ABI. Some things make
> > > sense; others are genuinely bad ideas while still possible.
> > >
> > In particular, to layer AppArmor on top of SELinux, the following
> > problems must be addressed:
> >
> > * New files: when a file is created, it is labeled according to the
> > type of the creating process and the type of the parent directory.
> > Applications can also use libselinux to use application logic to
> > relabel the file, but that is not 'mandatory' policy, and fails in
> > cases like cp and mv. AppArmor lets you create a policy that e..g
> > says "/home/*/.plan r" to permit fingerd to read everyone's .plan
> > file, should it ever exist, and you cannot emulate that with SELinux.
>
> A daemon using inotify can "instantly"[1] detect this and label the file
> properly if it shows up.
Or just create the files with restrictive labels by default. That way
you "fail closed".
> > * Renamed Files: Renaming a file changes the policy with respect to
> > that file in AA. To emulate this in SELinux, you would have to
> > have a way to instantly re-label the file upon rename.
>
> Same daemon can do the re-label.
...and no, race there is not important. Attacker may have opened the
file under old name and is keeping open file descriptor. So this does
not add a new race relative to AA.
> > * Renamed Directory trees: The above problem is compounded with
> > directory trees. Changing the name at the top of a large, bushy
> > tree can require instant relabeling of millions of files.
>
> Same daemon can do this. And yes, it might take a ammount of time, but
> the times that this happens in "real-life" on a "production" server is
> quite small, if at all.
And now, if you move a tree, there will be old labels for a while. But
this does not matter, because attacker could be keeping file
descriptors.
Only case where attacker _can't_ be keeping file descriptors is newly
created files in recently moved tree. But as you already create files
with restrictive permissions, that's okay.
Yes, you may get some -EPERM during the tree move, but AA has that
problem already, see that "when madly moving trees we sometimes
construct path file never ever had".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--- Stephen Smalley <[email protected]> wrote:
> On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote:
> > --- Greg KH <[email protected]> wrote:
> >
> >
> > > A daemon using inotify can "instantly"[1] detect this and label the file
> > > properly if it shows up.
> >
> > In our 1995 B1 evaluation of Trusted Irix we were told in no
> > uncertain terms that such a solution was not acceptable under
> > the TCSEC requirements. Detection and relabel on an unlocked
> > object creates an obvious window for exploitation. We were told
> > that such a scheme would be considered a design flaw.
> >
> > I understand that some of the Common Criteria labs are less
> > aggressive regarding chasing down these issues than the NCSC
> > teams were. It might not prevent an evaluation from completing
> > today. It is still hard to explain why it's ok to have a file
> > that's labeled incorrectly _even briefly_. It is the systems
> > job to ensure that that does not happen.
>
> Um, Casey, he is talking about how to emulate AppArmor behavior on a
> label-based system like SELinux,
Yes. What I'm saying (or trying to) is that such an implementation
would be flawed by design.
> not meeting B1 or LSPP or anything like that
> (which AppArmor can't do regardless).
We're not talking about an implementation based on AppArmor. As
you point out, we're talking about implementing name based access
control as an extension of SELinux.
> As far as general issue
> goes, if your policy is configured such that the new file gets the most
> restrictive label possible at creation time and then the daemon relabels
> it to a less restrictive label if appropriate, then there is no actual
> window of exposure.
Is it general practice to configure policy such that "the new file gets
the most restrictive label possible at creation time"? I confess that
my understanding of the current practice in policy generation is based
primarily on a shouted conversation in a crowded Irish pub.
> Also, there is such a daemon, restorecond, in SELinux (policycoreutils)
> although we avoid relying on it for anything security-critical
> naturally.
Yes, I am aware of restorecond. I find the need for restorecond troubling.
> And one could introduce the named type transition concept
> that has been discussed in this thread without much difficulty to
> selinux.
Yup, I see that once you accept the notion that it is OK for a
file to be misslabeled for a bit and that having a fixxerupperd
is sufficient it all falls out.
My point is that there is a segment of the security community
that had not found this acceptable, even under the conditions
outlined. If it meets your needs, I say run with it.
Casey Schaufler
[email protected]
On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> Hi!
>
> And before you scream "races", take a look. It does not actually add
> them:
Hey, I never screamed that at all, in fact, I completly agree with you
:)
> > > > I agree that the in-kernel implementation could use different abstractions
> > > > than user-space, provided that the underlying implementation details can be
> > > > hidden well enough. The key phrase here is "if possible", and in fact "if
> > > > possible" is much too strong: very many things in software are possible,
> > > > including user-space drives and a stable kernel module ABI. Some things make
> > > > sense; others are genuinely bad ideas while still possible.
> > > >
> > > In particular, to layer AppArmor on top of SELinux, the following
> > > problems must be addressed:
> > >
> > > * New files: when a file is created, it is labeled according to the
> > > type of the creating process and the type of the parent directory.
> > > Applications can also use libselinux to use application logic to
> > > relabel the file, but that is not 'mandatory' policy, and fails in
> > > cases like cp and mv. AppArmor lets you create a policy that e..g
> > > says "/home/*/.plan r" to permit fingerd to read everyone's .plan
> > > file, should it ever exist, and you cannot emulate that with SELinux.
> >
> > A daemon using inotify can "instantly"[1] detect this and label the file
> > properly if it shows up.
>
> Or just create the files with restrictive labels by default. That way
> you "fail closed".
>From my limited knowledge of SELinux, this is the default today so this
would happen by default. Anyone with more SELinux experience want to
verify or fix my understanding of this?
> > > * Renamed Files: Renaming a file changes the policy with respect to
> > > that file in AA. To emulate this in SELinux, you would have to
> > > have a way to instantly re-label the file upon rename.
> >
> > Same daemon can do the re-label.
>
> ...and no, race there is not important. Attacker may have opened the
> file under old name and is keeping open file descriptor. So this does
> not add a new race relative to AA.
Agreed.
> > > * Renamed Directory trees: The above problem is compounded with
> > > directory trees. Changing the name at the top of a large, bushy
> > > tree can require instant relabeling of millions of files.
> >
> > Same daemon can do this. And yes, it might take a ammount of time, but
> > the times that this happens in "real-life" on a "production" server is
> > quite small, if at all.
>
> And now, if you move a tree, there will be old labels for a while. But
> this does not matter, because attacker could be keeping file
> descriptors.
Agreed.
> Only case where attacker _can't_ be keeping file descriptors is newly
> created files in recently moved tree. But as you already create files
> with restrictive permissions, that's okay.
>
> Yes, you may get some -EPERM during the tree move, but AA has that
> problem already, see that "when madly moving trees we sometimes
> construct path file never ever had".
Exactly.
I can't think of a "real world" use of moving directory trees around
that this would come up in as a problem. Maybe a source code control
system might have this issue for the server, but in a second or two
everything would be working again as the new files would be relabled
correctly.
Can anyone else see a problem with this that I'm just being foolish and
missing?
thanks,
greg k-h
On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
>
> Yup, I see that once you accept the notion that it is OK for a
> file to be misslabeled for a bit and that having a fixxerupperd
> is sufficient it all falls out.
>
> My point is that there is a segment of the security community
> that had not found this acceptable, even under the conditions
> outlined. If it meets your needs, I say run with it.
If that segment feels that way, then I imagine AA would not meet their
requirements today due to file handles and other ways of passing around
open files, right?
So, would SELinux today (without this AA-like daemon) fit the
requirements of this segment?
thanks,
greg k-h
On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> >
> > Yup, I see that once you accept the notion that it is OK for a
> > file to be misslabeled for a bit and that having a fixxerupperd
> > is sufficient it all falls out.
> >
> > My point is that there is a segment of the security community
> > that had not found this acceptable, even under the conditions
> > outlined. If it meets your needs, I say run with it.
>
> If that segment feels that way, then I imagine AA would not meet their
> requirements today due to file handles and other ways of passing around
> open files, right?
>
> So, would SELinux today (without this AA-like daemon) fit the
> requirements of this segment?
>
Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC
using the features of SELinux where appropriate.
Karl
On Fri, 15 Jun 2007, Greg KH wrote:
> > Or just create the files with restrictive labels by default. That way
> > you "fail closed".
>
> From my limited knowledge of SELinux, this is the default today so this
> would happen by default. Anyone with more SELinux experience want to
> verify or fix my understanding of this?
This is entirely controllable via policy. That is, you specify that newly
create files are labeled to something safe (enforced atomically at the
kernel level), and then your userland relabeler would be invoked via
inotify to relabel based on your userland pathname specification.
This labeling policy can be as granular as you wish, from the entire
filesystem to a single file. It can also be applied depending on the
process which created the file and the directory its created in, ranging
from all processes and all directories, to say, just those running as
user_t in directories labeled as public_html_t (or whatever).
- James
--
James Morris
<[email protected]>
On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:
> On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> > On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > >
> > > Yup, I see that once you accept the notion that it is OK for a
> > > file to be misslabeled for a bit and that having a fixxerupperd
> > > is sufficient it all falls out.
> > >
> > > My point is that there is a segment of the security community
> > > that had not found this acceptable, even under the conditions
> > > outlined. If it meets your needs, I say run with it.
> >
> > If that segment feels that way, then I imagine AA would not meet their
> > requirements today due to file handles and other ways of passing around
> > open files, right?
> >
> > So, would SELinux today (without this AA-like daemon) fit the
> > requirements of this segment?
> >
>
> Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC
> using the features of SELinux where appropriate.
Great, but is there the requirement in the CC stuff such that this type
of "delayed re-label" that an AA-like daemon would need to do cause that
model to not be able to be certified like your SELinux implementation
is?
As I'm guessing the default "label" for things like this already work
properly for SELinux, I figure we should be safe, but I don't know those
requirements at all.
thanks,
greg k-h
On Fri, 2007-06-15 at 14:44 -0700, Greg KH wrote:
> On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:
> > On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> > > On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > > >
> > > > Yup, I see that once you accept the notion that it is OK for a
> > > > file to be misslabeled for a bit and that having a fixxerupperd
> > > > is sufficient it all falls out.
> > > >
> > > > My point is that there is a segment of the security community
> > > > that had not found this acceptable, even under the conditions
> > > > outlined. If it meets your needs, I say run with it.
> > >
> > > If that segment feels that way, then I imagine AA would not meet their
> > > requirements today due to file handles and other ways of passing around
> > > open files, right?
> > >
> > > So, would SELinux today (without this AA-like daemon) fit the
> > > requirements of this segment?
> > >
> >
> > Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC
> > using the features of SELinux where appropriate.
>
> Great, but is there the requirement in the CC stuff such that this type
> of "delayed re-label" that an AA-like daemon would need to do cause that
> model to not be able to be certified like your SELinux implementation
> is?
>
There are two things:
1) relabeling (non-tranquility) is very problematic in general because
revocation is hard (and non-solved in Linux). So you would have to
address concerns about that.
2) Whether this would pass certification depends on a lot of factors
(like the specific requirements - CC is just a process not a single set
of requirements). I don't know enough to really guess.
More to the point, though, the requirements in those documents are
outdated at best. I don't think it is worth worrying over.
> As I'm guessing the default "label" for things like this already work
> properly for SELinux, I figure we should be safe, but I don't know those
> requirements at all.
>
Probably not - you would likely want it to be a label that can't be read
or written by anything, only relabeled by the daemon.
Karl
--- Greg KH <[email protected]> wrote:
> On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> >
> > Yup, I see that once you accept the notion that it is OK for a
> > file to be misslabeled for a bit and that having a fixxerupperd
> > is sufficient it all falls out.
> >
> > My point is that there is a segment of the security community
> > that had not found this acceptable, even under the conditions
> > outlined. If it meets your needs, I say run with it.
>
> If that segment feels that way, then I imagine AA would not meet their
> requirements today due to file handles and other ways of passing around
> open files, right?
That segment is itself divided (think the "Judean Peoples Front"
and the "Peoples Front of Judea") on many issues, but as it has
always put correctness over ease of use I would expect AppArmor to
have a tough roe to hoe. There are other segments for which AppArmor
may well be appealing, and those segments have always been much
larger than Judea.
> So, would SELinux today (without this AA-like daemon) fit the
> requirements of this segment?
The JPF is head over heels in love with SELinux, restorecond and all.
The PFJ has some issues, but will most likely go along with the JPF
in part because the JPF is bringing the beer and besides, what are
their alternatives today? The PJF ("that's him, over there") is still
stunned by some of what SELinux accepts as normal (restorecond, 400,000
line "policy" definitions with embedded wildcards) and spends a lot
of time chanting the TCB Principle in hopes that it will help, but
no lightning strikes from above to date.
But you knew that. I'm an advocate of making a variety of alternates
available which is why I had originally proposed the authoritative
hooks version of the LSM and why I don't believe in rolling every
possible security facility into SELinux. I also believe in warning
people of pitfalls before they've impaled themselves on the spikes,
but some people gotta have the experience. Just trying to help.
Casey Schaufler
[email protected]
Greg KH wrote:
> On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
>
>>>> * Renamed Directory trees: The above problem is compounded with
>>>> directory trees. Changing the name at the top of a large, bushy
>>>> tree can require instant relabeling of millions of files.
>>>>
>>> Same daemon can do this. And yes, it might take a ammount of time, but
>>> the times that this happens in "real-life" on a "production" server is
>>> quite small, if at all.
>>>
>> And now, if you move a tree, there will be old labels for a while. But
>> this does not matter, because attacker could be keeping file
>> descriptors.
>>
> Agreed.
>
We have built a label-based AA prototype. It fails because there is no
reasonable way to address the tree renaming problem.
>> Only case where attacker _can't_ be keeping file descriptors is newly
>> created files in recently moved tree. But as you already create files
>> with restrictive permissions, that's okay.
>>
>> Yes, you may get some -EPERM during the tree move, but AA has that
>> problem already, see that "when madly moving trees we sometimes
>> construct path file never ever had".
>>
> Exactly.
>
You are remembering old behavior. The current AppArmor generates only
correct and consistent paths. If a process has an open file descriptor
to such a file, they will retain access to it, as we described here:
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
Under the restorecon-alike proposal, you have a HUGE open race. This
post http://bugs.centos.org/view.php?id=1981 describes restorecon
running for 30 minutes relabeling a file system. That is so far from
acceptable that it is silly.
Of course, this depends on the system in question, but restorecon will
necessarily need to traverse whatever portions of the filesystem that
have changed, which can be quite a long time indeed. Any race condition
measured in minutes is a very serious issue.
> I can't think of a "real world" use of moving directory trees around
> that this would come up in as a problem.
Consider this case: We've been developing a new web site for a month,
and testing it on the server by putting it in a different virtual
domain. We want to go live at some particular instant by doing an mv of
the content into our public HTML directory. We simultaneously want to
take the old web site down and archive it by moving it somewhere else.
Under the restorecon proposal, the web site would be horribly broken
until restorecon finishes, as various random pages are or are not
accessible to Apache.
In a smaller scale example, I want to share some files with a friend. I
can't be bothered to set up a proper access control system, so I just mv
the files to ~crispin/public_html/lookitme and in IRC say "get it now,
going away in 10 minutes" and then move it out again. Yes, you can
manually address this by running "restorecon ~crispin/public_html". But
AA does this automatically without having to run any commands.
You could get restorecon to do this automatically by using inotify. But
to make it as general and transparent as AA is now, you would have to
run inotify on every directory in the system, with consequences for
kernel memory and performance.
This problem does not exist for SELinux, because SELinux does not expect
access to change based on file names.
This problem does not exist in the proposed AA implementation, because
the patch makes the access decision based on the current name of the
file, so it doesn't have a consistency problem between the file and its
label; there is no label.
The problem is induced by trying to emulate AA on top of SELinux. They
don't fit well together. AA fits much better with LSM, which is the
reason LSM exists.
> Maybe a source code control
> system might have this issue for the server, but in a second or two
> everything would be working again as the new files would be relabled
> correctly.
>
Try an hour or two for a large source code repository. Its linear in the
number of files, and several hundred thousand files would take a while
to relabel. A large GIT tree would be particularly painful because of
the very large number of files.
> Can anyone else see a problem with this that I'm just being foolish and
> missing?
>
It is not foolish. The label idea is so attractive that last September
from discussions with Arjan we actually thought it was the preferred
implementation. However, what we've been saying over and over again is
that we *tried* this, and it *doesn't* work at the implementation level.
There is no good answer, restorecon is an ugly kludge, and so this
seductive approach turns out to be a dead end.
Caveat: I am *not* saying that labels in general are bad, just that they
are a bad way to emulate the AppArmor model. And yes, I am working on a
model paper that is more abstract than Andreas' paper
<http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf>,
but that takes time.
Then there's all the other problems, such as file systems that don't
support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable
to network attack, but that is not the threat AA is addressing. AA is
preventing an application with access to an NFS mount from accessing the
*entire* mount. There is lots of practical security value in this, and
label schemes cannot do it. Well, mostly; you could do it with a dynamic
labeling scheme that labels files as they are pulled into kernel memory,
but that requires an AA-style regexp parser in the kernel to apply the
labels.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor
On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> Yes, you may get some -EPERM during the tree move, but AA has that
> problem already, see that "when madly moving trees we sometimes
> construct path file never ever had".
Pavel, please focus on the current AppArmor implementation. You're
remembering a flaw with a previous version of AppArmor. The pathnames
constructed with the current version of AppArmor are consistent and
correct.
Thanks.
Hi!
> > Yes, you may get some -EPERM during the tree move, but AA has that
> > problem already, see that "when madly moving trees we sometimes
> > construct path file never ever had".
>
> Pavel, please focus on the current AppArmor implementation. You're
> remembering a flaw with a previous version of AppArmor. The pathnames
> constructed with the current version of AppArmor are consistent and
> correct.
Ok, I did not know that this got fixed.
How do you do that? Hold a lock preventing renames for a whole time
you walk from file to the root of filesystem?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, Jun 15, 2007 at 05:42:08PM -0400, James Morris wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
>
> > > Or just create the files with restrictive labels by default. That way
> > > you "fail closed".
> >
> > From my limited knowledge of SELinux, this is the default today so this
> > would happen by default. Anyone with more SELinux experience want to
> > verify or fix my understanding of this?
>
> This is entirely controllable via policy. That is, you specify that newly
> create files are labeled to something safe (enforced atomically at the
> kernel level), and then your userland relabeler would be invoked via
> inotify to relabel based on your userland pathname specification.
>
> This labeling policy can be as granular as you wish, from the entire
> filesystem to a single file. It can also be applied depending on the
> process which created the file and the directory its created in, ranging
> from all processes and all directories, to say, just those running as
> user_t in directories labeled as public_html_t (or whatever).
Oh great, then things like source code control systems would have no
problems with new files being created under them, or renaming whole
trees.
So, so much for the "it's going to be too slow re-labeling everything"
issue, as it's not even required for almost all situations :)
thanks for letting us know.
greg k-h
On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
> Greg KH wrote:
> > On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> >
> >>>> * Renamed Directory trees: The above problem is compounded with
> >>>> directory trees. Changing the name at the top of a large, bushy
> >>>> tree can require instant relabeling of millions of files.
> >>>>
> >>> Same daemon can do this. And yes, it might take a ammount of time, but
> >>> the times that this happens in "real-life" on a "production" server is
> >>> quite small, if at all.
> >>>
> >> And now, if you move a tree, there will be old labels for a while. But
> >> this does not matter, because attacker could be keeping file
> >> descriptors.
> >>
> > Agreed.
> >
> We have built a label-based AA prototype. It fails because there is no
> reasonable way to address the tree renaming problem.
How does inotify not work here? You are notified that the tree is
moved, your daemon goes through and relabels things as needed. In the
meantime, before the re-label happens, you might have the wrong label on
things, but "somehow" SELinux already handles this, so I think you
should be fine.
> >> Only case where attacker _can't_ be keeping file descriptors is newly
> >> created files in recently moved tree. But as you already create files
> >> with restrictive permissions, that's okay.
> >>
> >> Yes, you may get some -EPERM during the tree move, but AA has that
> >> problem already, see that "when madly moving trees we sometimes
> >> construct path file never ever had".
> >>
> > Exactly.
> >
> You are remembering old behavior. The current AppArmor generates only
> correct and consistent paths. If a process has an open file descriptor
> to such a file, they will retain access to it, as we described here:
> http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
>
> Under the restorecon-alike proposal, you have a HUGE open race. This
> post http://bugs.centos.org/view.php?id=1981 describes restorecon
> running for 30 minutes relabeling a file system. That is so far from
> acceptable that it is silly.
Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the
only problem we have here, it isn't an issue.
> Of course, this depends on the system in question, but restorecon will
> necessarily need to traverse whatever portions of the filesystem that
> have changed, which can be quite a long time indeed. Any race condition
> measured in minutes is a very serious issue.
Agreed, so we fix that. There are ways to speed those kinds of things
up quite a bit, and I imagine since the default SELinux behavior doesn't
use restorecon in this kind of use-case, no one has spent the time to do
the work.
> > I can't think of a "real world" use of moving directory trees around
> > that this would come up in as a problem.
> Consider this case: We've been developing a new web site for a month,
> and testing it on the server by putting it in a different virtual
> domain. We want to go live at some particular instant by doing an mv of
> the content into our public HTML directory. We simultaneously want to
> take the old web site down and archive it by moving it somewhere else.
>
> Under the restorecon proposal, the web site would be horribly broken
> until restorecon finishes, as various random pages are or are not
> accessible to Apache.
Usually you don't do that by doing a 'mv' otherwise you are almost
guaranteed stale and mixed up content for some period of time, not to
mention the issues surrounding paths that might be messed up.
> In a smaller scale example, I want to share some files with a friend. I
> can't be bothered to set up a proper access control system, so I just mv
> the files to ~crispin/public_html/lookitme and in IRC say "get it now,
> going away in 10 minutes" and then move it out again. Yes, you can
> manually address this by running "restorecon ~crispin/public_html". But
> AA does this automatically without having to run any commands.
I'm saying that the daemon will automatically do it for you, you don't
have to do anything on your own.
> You could get restorecon to do this automatically by using inotify.
Yes.
> But to make it as general and transparent as AA is now, you would have
> to run inotify on every directory in the system, with consequences for
> kernel memory and performance.
What "kernel memory and performance" issues are there? Your SLED
machine already has inotify running on every directory in the system
today, and you don't seem to have noticed that :)
> This problem does not exist for SELinux, because SELinux does not expect
> access to change based on file names.
Agreed.
> This problem does not exist in the proposed AA implementation, because
> the patch makes the access decision based on the current name of the
> file, so it doesn't have a consistency problem between the file and its
> label; there is no label.
No, that's not the issue here. The issue is if we can use the model
that AA is exporting to users and apply it to the model that the kernel
uses internally to access internal data structures.
> The problem is induced by trying to emulate AA on top of SELinux. They
> don't fit well together. AA fits much better with LSM, which is the
> reason LSM exists.
Not really, LSM is there because originally people thought that a
general-purpose "hook" layer would be useful for implementing different
security models. But for those types of models that do not map well to
internal kernel structures, perhaps they should be modeled on top of a
security system that does handle the internal kernel representation of
things in the way the kernel works.
> > Maybe a source code control
> > system might have this issue for the server, but in a second or two
> > everything would be working again as the new files would be relabled
> > correctly.
> >
> Try an hour or two for a large source code repository. Its linear in the
> number of files, and several hundred thousand files would take a while
> to relabel. A large GIT tree would be particularly painful because of
> the very large number of files.
No, git servers are only storing the sha files, not the "live" tree.
Well, if you want to waste space on your server you might have a copy of
the current tree, but that's a configuration problem on your system.
> > Can anyone else see a problem with this that I'm just being foolish and
> > missing?
> >
> It is not foolish. The label idea is so attractive that last September
> from discussions with Arjan we actually thought it was the preferred
> implementation. However, what we've been saying over and over again is
> that we *tried* this, and it *doesn't* work at the implementation level.
> There is no good answer, restorecon is an ugly kludge, and so this
> seductive approach turns out to be a dead end.
Great, have any code I can look at? It would be nice to start with an
already working implementation that is only slow instead of trying to
start from scratch.
> Then there's all the other problems, such as file systems that don't
> support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable
> to network attack, but that is not the threat AA is addressing. AA is
> preventing an application with access to an NFS mount from accessing the
> *entire* mount. There is lots of practical security value in this, and
> label schemes cannot do it. Well, mostly; you could do it with a dynamic
> labeling scheme that labels files as they are pulled into kernel memory,
> but that requires an AA-style regexp parser in the kernel to apply the
> labels.
You still haven't answered Stephen's response to NFSv3, so until then,
please don't trot out this horse.
thanks,
greg k-h
On Fri, 15 Jun 2007, Greg KH wrote:
> On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
>> Greg KH wrote:
>>> On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
>>>> Only case where attacker _can't_ be keeping file descriptors is newly
>>>> created files in recently moved tree. But as you already create files
>>>> with restrictive permissions, that's okay.
>>>>
>>>> Yes, you may get some -EPERM during the tree move, but AA has that
>>>> problem already, see that "when madly moving trees we sometimes
>>>> construct path file never ever had".
>>>>
>>> Exactly.
>>>
>> You are remembering old behavior. The current AppArmor generates only
>> correct and consistent paths. If a process has an open file descriptor
>> to such a file, they will retain access to it, as we described here:
>> http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
>>
>> Under the restorecon-alike proposal, you have a HUGE open race. This
>> post http://bugs.centos.org/view.php?id=1981 describes restorecon
>> running for 30 minutes relabeling a file system. That is so far from
>> acceptable that it is silly.
>
> Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the
> only problem we have here, it isn't an issue.
how do you 'fix' the laws of physics?
the problem is that with a directory that contains lots of files below it
you have to access all the files metadata to change the labels on it. it
can take significant amounts of time to walk the entire three and change
every file.
>>> I can't think of a "real world" use of moving directory trees around
>>> that this would come up in as a problem.
>> Consider this case: We've been developing a new web site for a month,
>> and testing it on the server by putting it in a different virtual
>> domain. We want to go live at some particular instant by doing an mv of
>> the content into our public HTML directory. We simultaneously want to
>> take the old web site down and archive it by moving it somewhere else.
>>
>> Under the restorecon proposal, the web site would be horribly broken
>> until restorecon finishes, as various random pages are or are not
>> accessible to Apache.
>
> Usually you don't do that by doing a 'mv' otherwise you are almost
> guaranteed stale and mixed up content for some period of time, not to
> mention the issues surrounding paths that might be messed up.
on the contrary, useing 'mv' is by far the cleanest way to do this.
mv htdocs htdocs.old;mv htdocs.new htdocs
this makes two atomic changes to the filesystem, but can generate
thousands to millions of permission changes as a result.
David Lang
Hi!
> >> Only case where attacker _can't_ be keeping file descriptors is newly
> >> created files in recently moved tree. But as you already create files
> >> with restrictive permissions, that's okay.
> >>
> >> Yes, you may get some -EPERM during the tree move, but AA has that
> >> problem already, see that "when madly moving trees we sometimes
> >> construct path file never ever had".
> >>
> > Exactly.
> >
> You are remembering old behavior. The current AppArmor generates only
> correct and consistent paths. If a process has an open file descriptor
> to such a file, they will retain access to it, as we described here:
Ok, so what I described was actually secure. Good.
> Under the restorecon-alike proposal, you have a HUGE open race. This
> post http://bugs.centos.org/view.php?id=1981 describes restorecon
> running for 30 minutes relabeling a file system. That is so far from
> acceptable that it is silly.
30 minutes during installation does not seem "silly" to me.
And that race does not make it insecure, because of the open file
descriptors. Good.
> Of course, this depends on the system in question, but restorecon will
> necessarily need to traverse whatever portions of the filesystem that
> have changed, which can be quite a long time indeed. Any race condition
> measured in minutes is a very serious issue.
You seem to imply it is security related, it is not. I can have open
files for hours or days.
> > I can't think of a "real world" use of moving directory trees around
> > that this would come up in as a problem.
> Consider this case: We've been developing a new web site for a month,
> and testing it on the server by putting it in a different virtual
> domain. We want to go live at some particular instant by doing an mv of
> the content into our public HTML directory. We simultaneously want to
> take the old web site down and archive it by moving it somewhere
> else.
And you do that exactly how, without the race? I do not think ve have
three_way_rename(name1, name2, name3) system call.
Notice that
1) mv can take minutes already if you move cross filesystem.
2) this is easily avoided by mv-ing somewhere with "same" permissons,
then doing quick moves when daemon is done.
> You could get restorecon to do this automatically by using inotify. But
> to make it as general and transparent as AA is now, you would have to
> run inotify on every directory in the system, with consequences for
> kernel memory and performance.
So you run inotify everywhere. IIRC beagle does it already.
> > Can anyone else see a problem with this that I'm just being foolish and
> > missing?
> >
> It is not foolish. The label idea is so attractive that last September
> from discussions with Arjan we actually thought it was the preferred
> implementation. However, what we've been saying over and over again is
> that we *tried* this, and it *doesn't* work at the implementation level.
> There is no good answer, restorecon is an ugly kludge, and so this
> seductive approach turns out to be a dead end.
Talking about dead ends... "just put path-based security module into
kernel" recently got pretty strong "NACK" from Christoph Hellwig (see
TOMOYO Linux thread), and I believe there was similar comment from Al
Viro in past. That seems to me as dead-endy as it gets. "mv takes 30
minutes" is road slightly covered with bushes... compared to that.
So we can either forget about AA completely, or take a way Christoph
did not "NACK". restorecond is such a way, and with inotify it should
be acceptable. find does _not_ take that long, not even for git trees.
pavel@amd:/data/l/linux$ time find . > /dev/null
0.04user 0.37system 11.50 (0m11.504s) elapsed 3.56%CPU
(If you wanted to be super-nice, you could introduce rename() helper
into glibc, that would do re-labeling synchronously, and only return
when it is done. All the nice applications call glibc anyway, and all
the exploits can't take advantage of it, because it is secure
already.).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sat, Jun 16, 2007 at 01:39:14AM +0200, Pavel Machek wrote:
> > Pavel, please focus on the current AppArmor implementation. You're
> > remembering a flaw with a previous version of AppArmor. The pathnames
> > constructed with the current version of AppArmor are consistent and
> > correct.
>
> Ok, I did not know that this got fixed.
>
> How do you do that? Hold a lock preventing renames for a whole time
> you walk from file to the root of filesystem?
We've improved d_path() to remove many of its previous shortcomings:
eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1
On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote:
> > We have built a label-based AA prototype. It fails because there is no
> > reasonable way to address the tree renaming problem.
>
> How does inotify not work here? You are notified that the tree is
> moved, your daemon goes through and relabels things as needed. In the
> meantime, before the re-label happens, you might have the wrong label on
> things, but "somehow" SELinux already handles this, so I think you
> should be fine.
SELinux does not relabel files when containing directories move, so it
is not a problem they've chosen to face.
How well does inotify handle running attached to every directory on a
typical Linux system?
> > Under the restorecon-alike proposal, you have a HUGE open race. This
> > post http://bugs.centos.org/view.php?id=1981 describes restorecon
> > running for 30 minutes relabeling a file system. That is so far from
> > acceptable that it is silly.
>
> Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the
> only problem we have here, it isn't an issue.
Restorecon traverses the filesystem from a specific down. In order to
apply to an entire system (as would be necessary to try to emulate
AppArmor's model using SELinux), restorecon would need to run on vast
portions of the filesystem often. (mv ~/public_html ~/archived; or tar
zxvf linux-*.tar.gz, etc.)
I'm not sure we need to run restorecon every time rename(2) is called.
> > Of course, this depends on the system in question, but restorecon will
> > necessarily need to traverse whatever portions of the filesystem that
> > have changed, which can be quite a long time indeed. Any race condition
> > measured in minutes is a very serious issue.
>
> Agreed, so we fix that. There are ways to speed those kinds of things
> up quite a bit, and I imagine since the default SELinux behavior doesn't
> use restorecon in this kind of use-case, no one has spent the time to do
> the work.
The time for restorecon is probably best imagined as a kind of 'du' that
also updates extended attributes as it does its work. It'd be very
difficult to improve on this.
> What "kernel memory and performance" issues are there? Your SLED
> machine already has inotify running on every directory in the system
> today, and you don't seem to have noticed that :)
I beg to differ. :)
Hi!
> >>Under the restorecon proposal, the web site would be horribly broken
> >>until restorecon finishes, as various random pages are or are not
> >>accessible to Apache.
> >
> >Usually you don't do that by doing a 'mv' otherwise you are almost
> >guaranteed stale and mixed up content for some period of time, not to
> >mention the issues surrounding paths that might be messed up.
>
> on the contrary, useing 'mv' is by far the cleanest way to do this.
>
> mv htdocs htdocs.old;mv htdocs.new htdocs
>
> this makes two atomic changes to the filesystem, but can generate
> thousands to millions of permission changes as a result.
Ok, so mv gets slower for big trees... and open() gets faster for deep
trees. Previously, open in current directory was one atomic read of
directory entry, now it has to read directory, and its parent, and its
parent parent, and its...
(Or am I wrong and getting full path does not need to bring anything
in, not even in cache-cold case?)
So, proposed solution has different performance tradeoffs, but should
still be a win -- opens are more common than moves.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, Jun 15, 2007 at 05:18:10PM -0700, Seth Arnold wrote:
> On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote:
> > > We have built a label-based AA prototype. It fails because there is no
> > > reasonable way to address the tree renaming problem.
> >
> > How does inotify not work here? You are notified that the tree is
> > moved, your daemon goes through and relabels things as needed. In the
> > meantime, before the re-label happens, you might have the wrong label on
> > things, but "somehow" SELinux already handles this, so I think you
> > should be fine.
>
> SELinux does not relabel files when containing directories move, so it
> is not a problem they've chosen to face.
>
> How well does inotify handle running attached to every directory on a
> typical Linux system?
Look at SLED and Beagle (taking the indexing logic out of the equation.)
It runs good enough that a major Linux vendor is willing to stake its
reputation on it :)
> > > Under the restorecon-alike proposal, you have a HUGE open race. This
> > > post http://bugs.centos.org/view.php?id=1981 describes restorecon
> > > running for 30 minutes relabeling a file system. That is so far from
> > > acceptable that it is silly.
> >
> > Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the
> > only problem we have here, it isn't an issue.
>
> Restorecon traverses the filesystem from a specific down. In order to
> apply to an entire system (as would be necessary to try to emulate
> AppArmor's model using SELinux), restorecon would need to run on vast
> portions of the filesystem often. (mv ~/public_html ~/archived; or tar
> zxvf linux-*.tar.gz, etc.)
>
> I'm not sure we need to run restorecon every time rename(2) is called.
Ok, so we optimize it. Putting speed issues aside right now as a "mere"
implementation details, I'm looking for logical reasons the AA model
will not work in this type of system.
> > > Of course, this depends on the system in question, but restorecon will
> > > necessarily need to traverse whatever portions of the filesystem that
> > > have changed, which can be quite a long time indeed. Any race condition
> > > measured in minutes is a very serious issue.
> >
> > Agreed, so we fix that. There are ways to speed those kinds of things
> > up quite a bit, and I imagine since the default SELinux behavior doesn't
> > use restorecon in this kind of use-case, no one has spent the time to do
> > the work.
>
> The time for restorecon is probably best imagined as a kind of 'du' that
> also updates extended attributes as it does its work. It'd be very
> difficult to improve on this.
Is that a bet? :)
> > What "kernel memory and performance" issues are there? Your SLED
> > machine already has inotify running on every directory in the system
> > today, and you don't seem to have noticed that :)
>
> I beg to differ. :)
The Beagle index backend is known to slow things down at times, yes, but
is that the fault of the inotify watches, or the use of mono and a
big-ass database on the system at the same time?
In the original inotify development, the issue was not inotify at all,
unless you have some newer numbers in this regard?
And Crispin mentioned that you all already implemented this. Do you
have the code around so that we can take a look at it?
thanks,
greg k-h
On Fri, Jun 15, 2007 at 05:01:25PM -0700, [email protected] wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
>
> > On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
> >> Greg KH wrote:
> >>> On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> >>>> Only case where attacker _can't_ be keeping file descriptors is newly
> >>>> created files in recently moved tree. But as you already create files
> >>>> with restrictive permissions, that's okay.
> >>>>
> >>>> Yes, you may get some -EPERM during the tree move, but AA has that
> >>>> problem already, see that "when madly moving trees we sometimes
> >>>> construct path file never ever had".
> >>>>
> >>> Exactly.
> >>>
> >> You are remembering old behavior. The current AppArmor generates only
> >> correct and consistent paths. If a process has an open file descriptor
> >> to such a file, they will retain access to it, as we described here:
> >> http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
> >>
> >> Under the restorecon-alike proposal, you have a HUGE open race. This
> >> post http://bugs.centos.org/view.php?id=1981 describes restorecon
> >> running for 30 minutes relabeling a file system. That is so far from
> >> acceptable that it is silly.
> >
> > Ok, so we fix it. Seriously, it shouldn't be that hard. If that's the
> > only problem we have here, it isn't an issue.
>
> how do you 'fix' the laws of physics?
>
> the problem is that with a directory that contains lots of files below it
> you have to access all the files metadata to change the labels on it. it can
> take significant amounts of time to walk the entire three and change every
> file.
Agreed, but you can do this in ways that are faster than others :)
> >>> I can't think of a "real world" use of moving directory trees around
> >>> that this would come up in as a problem.
> >> Consider this case: We've been developing a new web site for a month,
> >> and testing it on the server by putting it in a different virtual
> >> domain. We want to go live at some particular instant by doing an mv of
> >> the content into our public HTML directory. We simultaneously want to
> >> take the old web site down and archive it by moving it somewhere else.
> >>
> >> Under the restorecon proposal, the web site would be horribly broken
> >> until restorecon finishes, as various random pages are or are not
> >> accessible to Apache.
> >
> > Usually you don't do that by doing a 'mv' otherwise you are almost
> > guaranteed stale and mixed up content for some period of time, not to
> > mention the issues surrounding paths that might be messed up.
>
> on the contrary, useing 'mv' is by far the cleanest way to do this.
>
> mv htdocs htdocs.old;mv htdocs.new htdocs
>
> this makes two atomic changes to the filesystem, but can generate thousands
> to millions of permission changes as a result.
I agree, and yet, somehow, SELinux today handles this just fine, right?
:)
Let's worry about speed issues later on when a working implementation is
produced, I'm still looking for the logical reason a system like this
can not work properly based on the expected AA interface to users.
thanks,
greg k-h
Crispin Cowan wrote:
> In a smaller scale example, I want to share some files with a friend. I
> can't be bothered to set up a proper access control system, so I just mv
> the files to ~crispin/public_html/lookitme and in IRC say "get it now,
> going away in 10 minutes" and then move it out again. Yes, you can
> manually address this by running "restorecon ~crispin/public_html". But
> AA does this automatically without having to run any commands.
If you share ~crispin/public_html/lookitme by making a hard link,
does relabeling approach work?
I thought SELinux allows only one label for one file.
If AA (on the top of SELinux) tries to allow different permissions to
~crispin/public_html/lookitme and its original location,
either one of two pathnames won't be accessible as intended, will it?
On Fri, 15 Jun 2007, Greg KH wrote:
> Oh great, then things like source code control systems would have no
> problems with new files being created under them, or renaming whole
> trees.
It depends -- I think we may be talking about different things.
If you're using inotify to watch for new files and kick something in
userspace to relabel them, it could take a while to relabel a lot of
files, although there are likely some gains to be had from parallel
relabeling which we've not explored.
What I was saying is that you can use traditional SELinux labeling policy
underneath that to ensure that there is always a safe label on each file
before it is relabeled from userspace.
> So, so much for the "it's going to be too slow re-labeling everything"
> issue, as it's not even required for almost all situations :)
You could probably get an idea of the cost by running something like:
$ time find /usr/src/linux | xargs setfattr -n user.foo -v bar
On my system, it takes about 1.2 seconds to label a fully checked out
kernel source tree with ~23,000 files in this manner, on a stock standard
ext3 filesystem with a SATA drive.
- James
--
James Morris
<[email protected]>
On Fri, 15 Jun 2007, [email protected] wrote:
> on the contrary, useing 'mv' is by far the cleanest way to do this.
>
> mv htdocs htdocs.old;mv htdocs.new htdocs
>
> this makes two atomic changes to the filesystem, but can generate thousands to
> millions of permission changes as a result.
OTOH, you've performed your labeling up front, and don't have to
effectively relabel each file each time on each access, which is what
you're really doing with pathname labeling.
- James
--
James Morris
<[email protected]>
On Fri, 15 Jun 2007, Seth Arnold wrote:
> > How does inotify not work here? You are notified that the tree is
> > moved, your daemon goes through and relabels things as needed. In the
> > meantime, before the re-label happens, you might have the wrong label on
> > things, but "somehow" SELinux already handles this, so I think you
> > should be fine.
>
> SELinux does not relabel files when containing directories move, so it
> is not a problem they've chosen to face.
It's a deliberate design choice, and follows traditional Unix security
logic. DAC permissions don't change on every file in the subtree when you
mv directories, either.
- James
--
James Morris
<[email protected]>
On Fri, 15 Jun 2007, Seth Arnold wrote:
> The time for restorecon is probably best imagined as a kind of 'du' that
> also updates extended attributes as it does its work. It'd be very
> difficult to improve on this.
restorecon can most definitely be improved.
- James
--
James Morris
<[email protected]>
--- James Morris <[email protected]> wrote:
> On my system, it takes about 1.2 seconds to label a fully checked out
> kernel source tree with ~23,000 files in this manner
That's an eternity for that many files to be improperly labeled.
If, and the "if" didn't originate with me, your policy is
demonstrably correct (how do you do that?) for all domains
you could claim that the action is safe, if not ideal.
I can't say if an evaluation team would buy the "safe"
argument. They've been known to balk before.
Casey Schaufler
[email protected]
On Fri, 15 Jun 2007, Casey Schaufler wrote:
>
> --- James Morris <[email protected]> wrote:
>
> > On my system, it takes about 1.2 seconds to label a fully checked out
> > kernel source tree with ~23,000 files in this manner
>
> That's an eternity for that many files to be improperly labeled.
> If, and the "if" didn't originate with me, your policy is
> demonstrably correct (how do you do that?) for all domains
> you could claim that the action is safe, if not ideal.
> I can't say if an evaluation team would buy the "safe"
> argument. They've been known to balk before.
To clarify:
We are discussing a scheme where the underlying SELinux labeling policy
always ensures a safe label on a file, and then relabeling newly created
files according to their pathnames.
There is no expectation that this scheme would be submitted for
certification. Its purpose is to merely to provide pathname-based
labeling outside of the kernel.
- James
--
James Morris
<[email protected]>
On Fri, Jun 15, 2007 at 09:21:57PM -0400, James Morris wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
>
> > Oh great, then things like source code control systems would have no
> > problems with new files being created under them, or renaming whole
> > trees.
>
> It depends -- I think we may be talking about different things.
>
> If you're using inotify to watch for new files and kick something in
> userspace to relabel them, it could take a while to relabel a lot of
> files, although there are likely some gains to be had from parallel
> relabeling which we've not explored.
>
> What I was saying is that you can use traditional SELinux labeling policy
> underneath that to ensure that there is always a safe label on each file
> before it is relabeled from userspace.
Ok, yes, I think we are in violent agreement here :)
> > So, so much for the "it's going to be too slow re-labeling everything"
> > issue, as it's not even required for almost all situations :)
>
> You could probably get an idea of the cost by running something like:
>
> $ time find /usr/src/linux | xargs setfattr -n user.foo -v bar
>
> On my system, it takes about 1.2 seconds to label a fully checked out
> kernel source tree with ~23,000 files in this manner, on a stock standard
> ext3 filesystem with a SATA drive.
Yeah, that should be very reasonable. I'll wait to see Crispin's code
to work off of and see if I can get it to approach that kind of speed.
thanks,
greg k-h
Hi!
> > The question is: why not just extend SELinux to include AA functionality
> > rather than doing a whole new subsystem.
>
> Because, as hard as it seems for some people to believe,
> not everyone wants Type Enforcement. SELinux is a fine
> implementation of type enforcement, but if you don't want
> what it does it would be silly to require that it be
> used in order to accomplish something else, like name based
> access control.
>
> If the same things made everyone feel "secure" there would be
> no optional security facilities (audit, cryptfs, /dev/random, ACLs).
> It appears that the AA folks are sufficiently unimpressed with
> SELinux they want to do something different. I understand that
Actually, no. AA was started at time when SELinux was very different
from today, and now AA people have installed base of 'happy users'
they are trying to support.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, 15 Jun 2007, Greg KH wrote:
>>> Usually you don't do that by doing a 'mv' otherwise you are almost
>>> guaranteed stale and mixed up content for some period of time, not to
>>> mention the issues surrounding paths that might be messed up.
>>
>> on the contrary, useing 'mv' is by far the cleanest way to do this.
>>
>> mv htdocs htdocs.old;mv htdocs.new htdocs
>>
>> this makes two atomic changes to the filesystem, but can generate thousands
>> to millions of permission changes as a result.
>
> I agree, and yet, somehow, SELinux today handles this just fine, right?
> :)
no it doesn't, SELinux as-is should take no action when the above command
is run, but SELinux implementing path-based permissions will have to
relabel every file or directory in both trees.
> Let's worry about speed issues later on when a working implementation is
> produced, I'm still looking for the logical reason a system like this
> can not work properly based on the expected AA interface to users.
if you are willing to live with the race conditions from the slow
(re)labeling and write the software to scan the entire system to figure
out the right policies (and then use inotify to watch the entire system
for changes and (re)label the appropriate files) and accept that you can't
get any granular security for filesystems that don't nativly support it
you could make SELinux behave like AA.
but why should they be required to? are you saying that the LSM hooks are
not a valid API and should be removed with all future security modules
being based on SELinux?
David Lang
Greg KH wrote:
> A daemon using inotify can "instantly"[1] detect this and label the file
> properly if it shows up.
> Same daemon can do the re-label.
Can the daemon using inotify access to all pathnames in all process's namespaces?
Are the namespace the daemon has and the namespace of pathnames notified via inotify always the same?
On Sat, Jun 16, 2007 at 01:09:06AM -0700, [email protected] wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
>
> >>> Usually you don't do that by doing a 'mv' otherwise you are almost
> >>> guaranteed stale and mixed up content for some period of time, not to
> >>> mention the issues surrounding paths that might be messed up.
> >>
> >> on the contrary, useing 'mv' is by far the cleanest way to do this.
> >>
> >> mv htdocs htdocs.old;mv htdocs.new htdocs
> >>
> >> this makes two atomic changes to the filesystem, but can generate
> >> thousands
> >> to millions of permission changes as a result.
> >
> > I agree, and yet, somehow, SELinux today handles this just fine, right?
> > :)
>
> no it doesn't, SELinux as-is should take no action when the above command is
> run, but SELinux implementing path-based permissions will have to relabel
> every file or directory in both trees.
Agreed.
> > Let's worry about speed issues later on when a working implementation is
> > produced, I'm still looking for the logical reason a system like this
> > can not work properly based on the expected AA interface to users.
>
> if you are willing to live with the race conditions from the slow
> (re)labeling and write the software to scan the entire system to figure out
> the right policies (and then use inotify to watch the entire system for
> changes and (re)label the appropriate files) and accept that you can't get
> any granular security for filesystems that don't nativly support it you
> could make SELinux behave like AA.
You make it sound like such a pretty picture :)
Anyway, I don't think there are "race conditions", just a bit of a delay
at times for situations that are not common or "normal operations". And
as I think the speed issues can be drasticly reduced, I don't think
that's a really big deal just yet. I'm trying to determine if there's
any logical reason why we can't do this and have yet to see proof of
that.
> but why should they be required to? are you saying that the LSM hooks are
> not a valid API and should be removed with all future security modules being
> based on SELinux?
Woah, that's a huge logical jump that I am not willing to make at this
point in time.
The reason I am proposing this for AA is due to the impeadance between
the AA model and how the kernel internally works. A number of core
kernel VFS developers have objected to the AA code and changes because
of this problem and me and Pavel are here working to try to resolve this
in a way that is acceptable to everyone involved (kernel developers and
AA developers and AA end users.)
I'll leave the whole "LSM should be just replaced with SELinux"
discussion for later, as it is not relevant to this current topic at
all.
thanks,
greg k-h
On Sun, Jun 17, 2007 at 12:44:08AM +0900, Tetsuo Handa wrote:
> Greg KH wrote:
> > A daemon using inotify can "instantly"[1] detect this and label the file
> > properly if it shows up.
>
> > Same daemon can do the re-label.
>
> Can the daemon using inotify access to all pathnames in all process's
> namespaces?
I don't see why not, do you?
> Are the namespace the daemon has and the namespace of pathnames
> notified via inotify always the same?
If they are in the same namespace, then yes, they will as far as I can
tell. Do you think this is incorrect?
thanks,
greg k-h
Greg KH wrote:
> On Sun, Jun 17, 2007 at 12:44:08AM +0900, Tetsuo Handa wrote:
> > Can the daemon using inotify access to all pathnames in all process's
> > namespaces?
>
> I don't see why not, do you?
>
> > Are the namespace the daemon has and the namespace of pathnames
> > notified via inotify always the same?
>
> If they are in the same namespace, then yes, they will as far as I can
> tell. Do you think this is incorrect?
At least, I think SELinux's "make relabel" can't relabel
files that are not in the namespace of "make" process.
I don't know how to use inotify, but what I worried is ...
If there are cases they are in different namespace,
it is impossible to relabel using userland daemon
(i.e. deferred-relabeling won't work)
unless all pathnames of all namespaces are somehow
accessible via inotify.
Thanks.
--- James Morris <[email protected]> wrote:
> On Fri, 15 Jun 2007, Casey Schaufler wrote:
>
> >
> > --- James Morris <[email protected]> wrote:
> >
> > > On my system, it takes about 1.2 seconds to label a fully checked out
> > > kernel source tree with ~23,000 files in this manner
> >
> > That's an eternity for that many files to be improperly labeled.
> > If, and the "if" didn't originate with me, your policy is
> > demonstrably correct (how do you do that?) for all domains
> > you could claim that the action is safe, if not ideal.
> > I can't say if an evaluation team would buy the "safe"
> > argument. They've been known to balk before.
>
> To clarify:
>
> We are discussing a scheme where the underlying SELinux labeling policy
> always ensures a safe label on a file, and then relabeling newly created
> files according to their pathnames.
To counter clarify:
You are saying two things:
1. The policy always ensures a safe label.
2. Files can be relabeled in a reasonable and timely manner.
I have no questions about 2. It's a hack, but you've already
acknowledged that and it will work, allowing for some potential
cases where someone is overeager about getting a file-in-transition.
Regarding 1: This is a founding premise of the arguement, that
the "policy" is written correctly such that there is no case
where a file gets created with an unsafe label. Given the external
nature of the policy, and the number of attributes used within
the policy, and the overall sophistication of the policy mechanism,
how does one ...
a. know that a label is "safe"
b. know that a file will get a "safe" label
c. know that the policy is "correctly" written as required
The question is not if fixxerupperd can set things right.
The question is about the properly written policy that is
required to make the mechanism worth discussing.
> There is no expectation that this scheme would be submitted for
> certification.
De-nial.
> Its purpose is to merely to provide pathname-based
> labeling outside of the kernel.
If you already have an in-kernel labeling scheme that you
trust to make the world safe until you get around to doing
the labeling externally you can argue that it's good enough.
But, to quote Cinderella's Stepmother, "I said "if"".
Casey Schaufler
[email protected]
Casey Schaufler wrote:
> --- James Morris <[email protected]> wrote:
>
>
>> On Fri, 15 Jun 2007, Casey Schaufler wrote:
>>
>>
>>> --- James Morris <[email protected]> wrote:
>>>
>>>
>>>> On my system, it takes about 1.2 seconds to label a fully checked out
>>>> kernel source tree with ~23,000 files in this manner
>>>>
>>> That's an eternity for that many files to be improperly labeled.
>>> If, and the "if" didn't originate with me, your policy is
>>> demonstrably correct (how do you do that?) for all domains
>>> you could claim that the action is safe, if not ideal.
>>> I can't say if an evaluation team would buy the "safe"
>>> argument. They've been known to balk before.
>>>
>> To clarify:
>>
>> We are discussing a scheme where the underlying SELinux labeling policy
>> always ensures a safe label on a file, and then relabeling newly created
>> files according to their pathnames.
>>
>
> To counter clarify:
>
> You are saying two things:
> 1. The policy always ensures a safe label.
> 2. Files can be relabeled in a reasonable and timely manner.
>
> I have no questions about 2. It's a hack, but you've already
> acknowledged that and it will work, allowing for some potential
> cases where someone is overeager about getting a file-in-transition.
>
> Regarding 1: This is a founding premise of the arguement, that
> the "policy" is written correctly such that there is no case
> where a file gets created with an unsafe label. Given the external
> nature of the policy, and the number of attributes used within
> the policy, and the overall sophistication of the policy mechanism,
> how does one ...
>
> a. know that a label is "safe"
> b. know that a file will get a "safe" label
> c. know that the policy is "correctly" written as required
>
> The question is not if fixxerupperd can set things right.
> The question is about the properly written policy that is
> required to make the mechanism worth discussing.
>
>
There are only about 850 file type_transition rules in the policy
shipped with RHEL and the vast majority of them are templated so this
isn't as hard as you think. Most are things like:
type_transition ftpd_t tmp_t : file ftpd_tmp_t;
which 1) don't require relabeling to something else and 2) very easy to
audit. A quick look suggests that the potentially less-restrictive label
is never chosen, for example you'll see:
type_transition groupadd_t etc_t : file shadow_t;
type_transition useradd_t etc_t : file shadow_t;
Instead of the default transition being etc_t they are labeled as
shadow_t (more restrictive) and then potentially relabled to etc_t.
That said, the lack of a type_transition in this case is as important as
having one if the default type (the parent directory) is less
restrictive. We already have tools that analyze policy and even tools to
warn about potential errors in policy (apol and sechecker). It might be
a good idea to add some more analysis to these tools to point out
potential labeling errors that can be used in automatic analysis, which
shouldn't be hard, I'll be sure to suggest that to the setools developers.
>> There is no expectation that this scheme would be submitted for
>> certification.
>>
>
> De-nial.
>
>
Several systems have gone off to ct&e and none of them use restorecond.
These are custom build systems and relabeling is kept to a minimum and
the applications are architected in a way that precludes this being
necessary so I don't know what you are trying to get at here.
>> Its purpose is to merely to provide pathname-based
>> labeling outside of the kernel.
>>
>
> If you already have an in-kernel labeling scheme that you
> trust to make the world safe until you get around to doing
> the labeling externally you can argue that it's good enough.
> But, to quote Cinderella's Stepmother, "I said "if"".
>
The "if" for SELinux is alot easier than you suggest. It certainly
outweighs the disadvantages of the path based scheme IMHO.
On Fri, 2007-06-15 at 13:43 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <[email protected]> wrote:
>
> > On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote:
> > > --- Greg KH <[email protected]> wrote:
> > >
> > >
> > > > A daemon using inotify can "instantly"[1] detect this and label the file
> > > > properly if it shows up.
> > >
> > > In our 1995 B1 evaluation of Trusted Irix we were told in no
> > > uncertain terms that such a solution was not acceptable under
> > > the TCSEC requirements. Detection and relabel on an unlocked
> > > object creates an obvious window for exploitation. We were told
> > > that such a scheme would be considered a design flaw.
> > >
> > > I understand that some of the Common Criteria labs are less
> > > aggressive regarding chasing down these issues than the NCSC
> > > teams were. It might not prevent an evaluation from completing
> > > today. It is still hard to explain why it's ok to have a file
> > > that's labeled incorrectly _even briefly_. It is the systems
> > > job to ensure that that does not happen.
> >
> > Um, Casey, he is talking about how to emulate AppArmor behavior on a
> > label-based system like SELinux,
>
> Yes. What I'm saying (or trying to) is that such an implementation
> would be flawed by design.
>
> > not meeting B1 or LSPP or anything like that
> > (which AppArmor can't do regardless).
>
> We're not talking about an implementation based on AppArmor. As
> you point out, we're talking about implementing name based access
> control as an extension of SELinux.
We're talking about emulating pathname-based security on SELinux.
Pathname-based security is inherently non-tranquil (names can change at
any time) and ambiguous (a single name may refer to different objects in
different namespaces, multiple names may refer to the same object in a
single namespace), and thus cannot possibly meet information flow /
classical confinement requirements. So using restorecond as the basis
for such an emulation loses nothing from what you already had. Using
restorecond as the fundamental basis for the security of SELinux itself
would be a bad thing, agreed.
> > As far as general issue
> > goes, if your policy is configured such that the new file gets the most
> > restrictive label possible at creation time and then the daemon relabels
> > it to a less restrictive label if appropriate, then there is no actual
> > window of exposure.
>
> Is it general practice to configure policy such that "the new file gets
> the most restrictive label possible at creation time"? I confess that
> my understanding of the current practice in policy generation is based
> primarily on a shouted conversation in a crowded Irish pub.
>
> > Also, there is such a daemon, restorecond, in SELinux (policycoreutils)
> > although we avoid relying on it for anything security-critical
> > naturally.
>
> Yes, I am aware of restorecond. I find the need for restorecond troubling.
Understand that we view it as a method of last resort, only to be
considered after trying first to:
1) Configure policy transparently to label the file correctly at
creation time (based on the creating process' label, the parent
directory label, and the kind of file), or if that fails,
2) Modify the library or application code to label the file correctly at
creation time (e.g. when multiple files that should be protected
differently are created by the same process in the same directory,
e.g. /etc/passwd vs. /etc/shadow).
> > And one could introduce the named type transition concept
> > that has been discussed in this thread without much difficulty to
> > selinux.
>
> Yup, I see that once you accept the notion that it is OK for a
> file to be misslabeled for a bit and that having a fixxerupperd
> is sufficient it all falls out.
I think you misunderstand what I mean by named type transition here -
that is a reference to earlier discussions in this thread on extending
the SELinux type_transition statements to let the kernel directly label
new files based not only on creating process and parent directory label
but also the last component name. With such an extension, SELinux could
directly distinguish e.g. /etc/shadow from /etc/passwd at file creation
time in the kernel without needing anything like restorecond in
userspace. There is no temporary mislabeling with such a mechanism.
--
Stephen Smalley
National Security Agency
On Fri, 2007-06-15 at 18:24 -0400, Karl MacMillan wrote:
> On Fri, 2007-06-15 at 14:44 -0700, Greg KH wrote:
> > On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:
> > > On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> > > > On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > > > >
> > > > > Yup, I see that once you accept the notion that it is OK for a
> > > > > file to be misslabeled for a bit and that having a fixxerupperd
> > > > > is sufficient it all falls out.
> > > > >
> > > > > My point is that there is a segment of the security community
> > > > > that had not found this acceptable, even under the conditions
> > > > > outlined. If it meets your needs, I say run with it.
> > > >
> > > > If that segment feels that way, then I imagine AA would not meet their
> > > > requirements today due to file handles and other ways of passing around
> > > > open files, right?
> > > >
> > > > So, would SELinux today (without this AA-like daemon) fit the
> > > > requirements of this segment?
> > > >
> > >
> > > Yes - RHEL 5 is going through CC evaluations for LSPP, CAPP, and RBAC
> > > using the features of SELinux where appropriate.
> >
> > Great, but is there the requirement in the CC stuff such that this type
> > of "delayed re-label" that an AA-like daemon would need to do cause that
> > model to not be able to be certified like your SELinux implementation
> > is?
> >
>
> There are two things:
>
> 1) relabeling (non-tranquility) is very problematic in general because
> revocation is hard (and non-solved in Linux). So you would have to
> address concerns about that.
I think we need to distinguish between relying on restorecond-like
mechanisms for the security of SELinux vs. relying on them for emulating
pathname-based security. The former would be a problem. The latter is
no worse than pathname-based security already, because pathname-based
security is inherently ambiguous and non-tranquil, and revocation isn't
addressed fully in AA either.
>
> 2) Whether this would pass certification depends on a lot of factors
> (like the specific requirements - CC is just a process not a single set
> of requirements). I don't know enough to really guess.
>
> More to the point, though, the requirements in those documents are
> outdated at best. I don't think it is worth worrying over.
>
> > As I'm guessing the default "label" for things like this already work
> > properly for SELinux, I figure we should be safe, but I don't know those
> > requirements at all.
> >
>
> Probably not - you would likely want it to be a label that can't be read
> or written by anything, only relabeled by the daemon.
>
> Karl
>
--
Stephen Smalley
National Security Agency
Greg KH wrote:
> On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
>
>> Then there's all the other problems, such as file systems that don't
>> support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable
>> to network attack, but that is not the threat AA is addressing. AA is
>> preventing an application with access to an NFS mount from accessing the
>> *entire* mount. There is lots of practical security value in this, and
>> label schemes cannot do it. Well, mostly; you could do it with a dynamic
>> labeling scheme that labels files as they are pulled into kernel memory,
>> but that requires an AA-style regexp parser in the kernel to apply the
>> labels.
>>
> You still haven't answered Stephen's response to NFSv3, so until then,
> please don't trot out this horse.
>
Ok then ...
Stephen Smalley wrote:
> - File systems that do not support labels: I'm a bit surprised that you
> would advocate this given your experience in developing EA and ACL
> support for local filesystems and NFS. The pathname-based approach in
> NFS seems even scarier than in the local case - the clients may have
> different views of the namespace than one another or the server and the
> potential for inconsistent views of the tree (particularly as it is
> being modified) during access checks is only greater in the NFS case,
> right? It may be more expedient to implement, but is it the right
> technical approach?
I'm actually unclear on what the question is. Stephen appears to be
thinking of confining the NFS server daemon, and our intended use case
is to use AppArmor to confine applications that access data on NFS clients.
* Each NFS *client* machine has a view of the NFS mount point that
is consistent for that client.
* The AA confinement is of the application accessing the NFS mount
on the client, *not* the NFS server daemon.
* The fact that the views of multiple clients are different from
each other is irrelevant, because we are confining applications on
the client, not the NFS server daemon.
* As noted in Andreas' technical document
http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/techdoc.pdf
there is no purpose to confining the NFS server daemon; it is a
kernel process, and if it mis-behaves, it can completely subvert
any kernel security policy, including AA and SELinux.
Since this point seems to be subtle, here's a motivating example.
Consider I have a diskless workstation, and my home dir /home/crispin is
NFS mounted from a big NAS server over there. I like to run my FireFox
confined, so that it only has access to /home/crispin/.mozilla/** and
/home/crispin/Downloads/** so that if my browser is compromised, the
attacker doesn't get to my /home/.ssh* stuff.
Yes, the data served over NFS is vulnerable to a local network attack,
but that is not what AA is preventing here. The threat is coming from
attacks that make the web browser misbehave.
Under SELinux, I either give the web browser access to all of
/home/crispin (the entire mount point) or none of it. Under AA, the
pathname specification works fine, we can control which directories on
the mount point the application can access.
The same argument applies to server applications that access data served
NFS mount points. Consider a large application server that hosts all my
enterprise resource management stuff, and a large NAS server that hosts
the data. Perhaps the NAS server is a Network Appliance server, not even
using a Linux file system, just supplying NFS3 mounts.
The application server is hosting both the payroll system and the
customer relationship application. The data for both are on the NetApp,
serviced via NFS to the application server. I want to confine the
payroll application to access only the payroll data, and the CRM
application to access only CRM data.
The only way SELinux could do this would be to have anticipated the
problem and store my data on separate partitions, so you could supply
separate mount points. AppArmor can just use path specifications to
confine each application to its own part of a single NFS mount point. In
a perfect world the admin would use separate mount points, AppArmor is a
tool for an imperfect world.
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor
Hi!
> > In a smaller scale example, I want to share some files with a friend. I
> > can't be bothered to set up a proper access control system, so I just mv
> > the files to ~crispin/public_html/lookitme and in IRC say "get it now,
> > going away in 10 minutes" and then move it out again. Yes, you can
> > manually address this by running "restorecon ~crispin/public_html". But
> > AA does this automatically without having to run any commands.
> If you share ~crispin/public_html/lookitme by making a hard link,
> does relabeling approach work?
> I thought SELinux allows only one label for one file.
> If AA (on the top of SELinux) tries to allow different permissions to
> ~crispin/public_html/lookitme and its original location,
> either one of two pathnames won't be accessible as intended, will it?
Yes, that's a bug/feature in AA. No, selinux will not be able to emulate that
bug/feature. Yes, it is dangerous, as it makes AA mostly useless on
multiuser machines.
(ln /etc/shadow /tmp is something any user can do, and all you need is
to exploit any daemon with access to /tmp).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Monday 18 June 2007 15:33, Stephen Smalley wrote:
> On Fri, 2007-06-15 at 18:24 -0400, Karl MacMillan wrote:
> > There are two things:
> >
> > 1) relabeling (non-tranquility) is very problematic in general because
> > revocation is hard (and non-solved in Linux). So you would have to
> > address concerns about that.
>
> I think we need to distinguish between relying on restorecond-like
> mechanisms for the security of SELinux vs. relying on them for emulating
> pathname-based security. The former would be a problem. The latter is
> no worse than pathname-based security already, because pathname-based
> security is inherently ambiguous and non-tranquil, and revocation isn't
> addressed fully in AA either.
Emulation using lazy relabeling introduces a window where the files have the
wrong label. In those windows, the pathname based policy is being violated,
and unintended side effects are suddenly possible. This includes granting of
access to files that applications should no longer have access to according
to the pathname based policy, which would be similar to what happens when a
process keeps an open file handle right now. But it also includes denial of
access to files that applications should have access to, and this might cause
those applications to fail. So this is where relabeling from user space is
much worse.
The only way to get rid of the denial of service problem would be to make the
rename and relabel an atomic operation. The time this can take is huge
though, so that's not acceptable.
Another, less catastrophic problem is that rename has always been relatively
fast and inexpensive, and I'm sure plenty of applications rely on this
performance characteristic. Making rename a very expensive operation in at
least some cases (which are more than theoretical) would hurt those
applications, and nothing much could be done about it.
Adding better new-file mechanisms to SELinux probably is a good idea, and it
would weaken the SELinux seurity model for all I can tell. It doesn't address
the relabeling problem though.
Andreas
On Saturday 16 June 2007 01:49, Greg KH wrote:
> But for those types of models that do not map well to internal kernel
> structures, perhaps they should be modeled on top of a security system that
> does handle the internal kernel representation of things in the way the
> kernel works.
How exactly are struct vfsmount and struct dentry not in-kernel structures?
Andreas
I've caught up on this thread with growing disbelief while reading the
mails, so much that I've found it hard to decide where to reply to.
So people are claiming that AA is ugly, because it introduces pathnames
and possibly a regex interpreter. Ok, taste differs. We've got many
different flavours of filesystems in the kernel because of that.
However, the suggested cure makes me cringe.
You're saying that relabeling file(s) from user-space after a rename is
a possible solution.
This breaks POSIX - renames must be atomic. It is possibly insecure; if
this is fixed by making a rename automatically default to restrictive
permissions, it'll be even more inconvenient. It will break applications
which expect to be able to access the file(s) immediately after a
rename. It is slow, and can possibly cause a lot of disk access.
Possibly over NFS or via slow disks. By going through user-space - which
could block and introduce all sorts of memory deadlocks (compared to
that deadlock, a regex is harmless.) (I also wonder how you propose to
relabel files on a r/o mount if the policy changes, btw; or if the NFS
mount is made available on several nodes w/different permissions.) AA
only enforces user-space defined policy - the argument that policy
doesn't belong into the kernel is bull. Adding a wrapper to glibc to
block until relabeling is complete?
"Let's first do the implementation and later worry about performance."?
"The timing window is neglible."? "30 minutes during installation does
not seem silly."?
You _must_ be kidding. The cure is worse than the problem.
If that is the only way to implement AA on top of SELinux - and so far,
noone has made a better suggestion - I'm convinced that AA has technical
merit: it does something the on-disk label based approach cannot handle,
and for which there is demand.
The code has improved, and continues to improve, to meet all the coding
style feedback except the bits which are essential to AA's function
(like the pathname lookup and the regex parser; though I'm sure that in
particular the later one could be swapped for a less complex matcher as
well). It certainly isn't worse than many other areas of the kernel.
You're pointing to each other's opposition to the features - that, my
dear gentlemen, is a circular argument. One of you could readily break
the chain.
This is trying to get rid of AA for the sake of it, masquerading as
technical reasons. At least fucking admit it. Don't lie. This is
distasteful.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
On Thu 2007-06-21 18:01:05, Andreas Gruenbacher wrote:
> On Saturday 16 June 2007 01:49, Greg KH wrote:
> > But for those types of models that do not map well to internal kernel
> > structures, perhaps they should be modeled on top of a security system that
> > does handle the internal kernel representation of things in the way the
> > kernel works.
>
> How exactly are struct vfsmount and struct dentry not in-kernel structures?
That's what greg is talking about, AFAICT. Normal kernel code uses
struct vfsmount + struct dentry.
AA uses... guess what... char pathname[HUGE_VALUE].
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> I've caught up on this thread with growing disbelief while reading the
> mails, so much that I've found it hard to decide where to reply to.
>
> So people are claiming that AA is ugly, because it introduces pathnames
> and possibly a regex interpreter. Ok, taste differs. We've got many
> different flavours of filesystems in the kernel because of that.
>
> However, the suggested cure makes me cringe.
>
> You're saying that relabeling file(s) from user-space after a rename is
> a possible solution.
>
> This breaks POSIX - renames must be atomic. It is possibly insecure; if
> this is fixed by making a rename automatically default to restrictive
> permissions, it'll be even more inconvenient. It will break
> applications
inconvenient, yes, insecure, no.
I believe AA breaks POSIX, already. rename() is not expected to change
permissions on target, nor is link link. And yes, both of these make
AA insecure.
> You _must_ be kidding. The cure is worse than the problem.
Possibly.
> If that is the only way to implement AA on top of SELinux - and so far,
> noone has made a better suggestion - I'm convinced that AA has technical
> merit: it does something the on-disk label based approach cannot handle,
> and for which there is demand.
What demand? SELinux is superior to AA, and there was very little
demand for AA. Compare demand for reiser4 or suspend2 with demand for
AA.
> The code has improved, and continues to improve, to meet all the coding
> style feedback except the bits which are essential to AA's function
Which are exactly the bits Christoph Hellwig and Al Viro
vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
. I believe it takes more than "2 users want it" to overcome veto of
VFS maintainer.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 2007-06-21T20:33:11, Pavel Machek <[email protected]> wrote:
> inconvenient, yes, insecure, no.
Well, only if you use the most restrictive permissions. And then you'll
suddenly hit failure cases which you didn't expect to, which can
possibly cause another exploit to become visible.
> I believe AA breaks POSIX, already. rename() is not expected to change
> permissions on target, nor is link link. And yes, both of these make
> AA insecure.
AA is supposed to allow valid access patterns, so for non-buggy apps +
policies, the rename will be fine and does not change the (observed)
permissions.
The time window in the rename+relabel approach however introduces a slot
where permissions are not consistent. This is a different case.
> > You _must_ be kidding. The cure is worse than the problem.
> Possibly.
Yes.
> > If that is the only way to implement AA on top of SELinux - and so far,
> > noone has made a better suggestion - I'm convinced that AA has technical
> > merit: it does something the on-disk label based approach cannot handle,
> > and for which there is demand.
> What demand? SELinux is superior to AA, and there was very little
> demand for AA. Compare demand for reiser4 or suspend2 with demand for
> AA.
SELinux is superior to AA for a certain scenario of use cases; as we can
see here, it is not superior to AA for _all_ use cases.
> > The code has improved, and continues to improve, to meet all the coding
> > style feedback except the bits which are essential to AA's function
> Which are exactly the bits Christoph Hellwig and Al Viro
> vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
> . I believe it takes more than "2 users want it" to overcome veto of
> VFS maintainer.
A veto is not a technical argument. All technical arguments (except for
"path name is ugly, yuk yuk!") have been addressed, have they not?
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
On Thu, 21 Jun 2007, Pavel Machek wrote:
>> If that is the only way to implement AA on top of SELinux - and so far,
>> noone has made a better suggestion - I'm convinced that AA has technical
>> merit: it does something the on-disk label based approach cannot handle,
>> and for which there is demand.
>
> What demand? SELinux is superior to AA, and there was very little
> demand for AA. Compare demand for reiser4 or suspend2 with demand for
> AA.
well, if you _really_ want people who are interested in this to do weekly
"why isn't it merged yet you $%#$%# developers" threads that can be
arranged.
the people who want this have been trying to be patient and let the system
work. if it takes people being pests to get something implemented it can
be done, but I don't think other people on the list will appriciate this.
>> The code has improved, and continues to improve, to meet all the coding
>> style feedback except the bits which are essential to AA's function
>
> Which are exactly the bits Christoph Hellwig and Al Viro
> vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
> . I believe it takes more than "2 users want it" to overcome veto of
> VFS maintainer.
so you are saying that _any_ pathname based solution is not acceptable to
the kernel, no matter what?
David Lang
On 2007-06-21T12:30:08, [email protected] wrote:
> well, if you _really_ want people who are interested in this to do weekly
> "why isn't it merged yet you $%#$%# developers" threads that can be
> arranged.
>
> the people who want this have been trying to be patient and let the system
> work. if it takes people being pests to get something implemented it can
> be done, but I don't think other people on the list will appriciate this.
Please. We're so not going down _that_ route.
On Thu, 21 Jun 2007, Lars Marowsky-Bree wrote:
> A veto is not a technical argument. All technical arguments (except for
> "path name is ugly, yuk yuk!") have been addressed, have they not?
AppArmor doesn't actually provide confinement, because it only operates on
filesystem objects.
What you define in AppArmor policy does _not_ reflect the actual
confinement properties of the policy. Applications can simply use other
mechanisms to access objects, and the policy is effectively meaningless.
You might define this as a non-technical issue, but the fact that AppArmor
simply does not and can not work is a fairly significant consideration, I
would imagine.
- James
--
James Morris
<[email protected]>
Hi!
> >>The code has improved, and continues to improve, to meet all the coding
> >>style feedback except the bits which are essential to AA's function
> >
> >Which are exactly the bits Christoph Hellwig and Al Viro
> >vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
> >. I believe it takes more than "2 users want it" to overcome veto of
> >VFS maintainer.
>
> so you are saying that _any_ pathname based solution is not acceptable to
> the kernel, no matter what?
You'd have to ask Christoph the same question.
AFAICT, reconstructing full path then basing security on that is a
no-no.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 2007-06-21T15:42:28, James Morris <[email protected]> wrote:
> > A veto is not a technical argument. All technical arguments (except for
> > "path name is ugly, yuk yuk!") have been addressed, have they not?
> AppArmor doesn't actually provide confinement, because it only operates on
> filesystem objects.
>
> What you define in AppArmor policy does _not_ reflect the actual
> confinement properties of the policy. Applications can simply use other
> mechanisms to access objects, and the policy is effectively meaningless.
Only if they have access to another process which provides them with
that data.
And now, yes, I know AA doesn't mediate IPC or networking (yet), but
that's a missing feature, not broken by design.
> You might define this as a non-technical issue, but the fact that AppArmor
> simply does not and can not work is a fairly significant consideration, I
> would imagine.
If I restrict my Mozilla to not access my on-disk mail folder, it can't
get there. (Barring bugs in programs which Mozilla is allowed to run
unconfined, sure.)
If the argument is that AA provides somewhat different semantics - and
for some use cases "weaker" ones - than SE Linux, that is undoubtly
true. However, it appears to be the case that those are the differences
which make AA's model different from SELinux as well, so it appears a
trade-off best left to the admin / user to choose what fits their needs
best.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
Hi!
> > I believe AA breaks POSIX, already. rename() is not expected to change
> > permissions on target, nor is link link. And yes, both of these make
> > AA insecure.
>
> AA is supposed to allow valid access patterns, so for non-buggy apps +
> policies, the rename will be fine and does not change the (observed)
> permissions.
That still breaks POSIX, right? Hopefully it will not break any apps,
but...
> > > If that is the only way to implement AA on top of SELinux - and so far,
> > > noone has made a better suggestion - I'm convinced that AA has technical
> > > merit: it does something the on-disk label based approach cannot handle,
> > > and for which there is demand.
> > What demand? SELinux is superior to AA, and there was very little
> > demand for AA. Compare demand for reiser4 or suspend2 with demand for
> > AA.
>
> SELinux is superior to AA for a certain scenario of use cases; as we can
> see here, it is not superior to AA for _all_ use cases.
The scenario where it does not seem superior is "I have system with AA
here and I'd like to keep using it".
> > > The code has improved, and continues to improve, to meet all the coding
> > > style feedback except the bits which are essential to AA's function
> > Which are exactly the bits Christoph Hellwig and Al Viro
> > vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
> > . I believe it takes more than "2 users want it" to overcome veto of
> > VFS maintainer.
>
> A veto is not a technical argument. All technical arguments (except for
> "path name is ugly, yuk yuk!") have been addressed, have they not?
There still is "it does not work with long pathnames".
Plus IIRC we have something like "AA has to allocate path-sized
buffers along every syscall".
I guess Al Viro or Christoph Hellwig would be able to detail on
that. I don't think they are vetoing stuff for fun.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 2007-06-21T22:07:40, Pavel Machek <[email protected]> wrote:
> > AA is supposed to allow valid access patterns, so for non-buggy apps +
> > policies, the rename will be fine and does not change the (observed)
> > permissions.
> That still breaks POSIX, right? Hopefully it will not break any apps,
> but...
No, it does not break POSIX.
Unless, of course, there's a bug in the policy or in the program. Bugs
are generally not covered by POSIX, for some strange reason.
(The argument that POSIX codifies implementation bugs in Unix(tm)
implementations of the time non-withstanding.)
> > A veto is not a technical argument. All technical arguments (except for
> > "path name is ugly, yuk yuk!") have been addressed, have they not?
> There still is "it does not work with long pathnames".
>
> Plus IIRC we have something like "AA has to allocate path-sized
> buffers along every syscall".
That is an implementation bug though. I'm sure we have other bugs in the
kernel too - this isn't a design flaw.
(If people are allowed to thinair solutions for implementing AA on top
of SELinux, I can thinair that this can be solved by reverse-matching
the dentry tree against the policy as the path is traversed and
constructed, requiring a constant sized buffer.)
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-21T15:42:28, James Morris <[email protected]> wrote:
>
> > > A veto is not a technical argument. All technical arguments (except for
> > > "path name is ugly, yuk yuk!") have been addressed, have they not?
> > AppArmor doesn't actually provide confinement, because it only operates on
> > filesystem objects.
> >
> > What you define in AppArmor policy does _not_ reflect the actual
> > confinement properties of the policy. Applications can simply use other
> > mechanisms to access objects, and the policy is effectively meaningless.
>
> Only if they have access to another process which provides them with
> that data.
Or can access the data under a different path to which their profile
does give them access, whether in its final destination or in some
temporary file processed along the way.
> And now, yes, I know AA doesn't mediate IPC or networking (yet), but
> that's a missing feature, not broken by design.
The incomplete mediation flows from the design, since the pathname-based
mediation doesn't generalize to cover all objects unlike label- or
attribute-based mediation. And the "use the natural abstraction for
each object type" approach likewise doesn't yield any general model or
anything that you can analyze systematically for data flow.
The emphasis on never modifying applications for security in AA likewise
has an adverse impact here, as you will ultimately have to deal with
application mediation of access to their own objects and operations not
directly visible to the kernel (as we have already done in SELinux for
D-BUS and others and are doing for X). Otherwise, your "protection" of
desktop applications is easily subverted.
> > You might define this as a non-technical issue, but the fact that AppArmor
> > simply does not and can not work is a fairly significant consideration, I
> > would imagine.
>
> If I restrict my Mozilla to not access my on-disk mail folder, it can't
> get there. (Barring bugs in programs which Mozilla is allowed to run
> unconfined, sure.)
Um, no. It might not be able to directly open files via that path, but
showing that it can never read or write your mail is a rather different
matter.
--
Stephen Smalley
National Security Agency
On 2007-06-21T16:59:54, Stephen Smalley <[email protected]> wrote:
> Or can access the data under a different path to which their profile
> does give them access, whether in its final destination or in some
> temporary file processed along the way.
Well, yes. That is intentional.
Your point is?
> The emphasis on never modifying applications for security in AA likewise
> has an adverse impact here, as you will ultimately have to deal with
> application mediation of access to their own objects and operations not
> directly visible to the kernel (as we have already done in SELinux for
> D-BUS and others and are doing for X). Otherwise, your "protection" of
> desktop applications is easily subverted.
That is an interesting argument, but not what we're discussing here.
We're arguing filesystem access mediation.
> Um, no. It might not be able to directly open files via that path, but
> showing that it can never read or write your mail is a rather different
> matter.
Yes. Your use case is different than mine.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
On Thu, Jun 21, 2007 at 10:21:07PM +0200, Lars Marowsky-Bree wrote:
> On 2007-06-21T22:07:40, Pavel Machek <[email protected]> wrote:
>
> >
> > Plus IIRC we have something like "AA has to allocate path-sized
> > buffers along every syscall".
>
> That is an implementation bug though. I'm sure we have other bugs in the
> kernel too - this isn't a design flaw.
>
> (If people are allowed to thinair solutions for implementing AA on top
> of SELinux, I can thinair that this can be solved by reverse-matching
> the dentry tree against the policy as the path is traversed and
> constructed, requiring a constant sized buffer.)
>
Indeed there are a few solutions to "fix" this implementation "bug",
of which reverse matching is one. For reverse matching the policy
tables would become larger. Reverse matching wouldn't need any
additional buffer for enforcement but would still fall back to d_path
for logging.
But we would still require the changes to the vfs and also a way to
safely walk the tree backwards. So we would need to either export the
namespace semaphore or add a generic walking function which we could
pass a hook function to.
Lars Marowsky-Bree wrote:
> On 2007-06-21T16:59:54, Stephen Smalley <[email protected]> wrote:
> <snip>
>
>
>> Um, no. It might not be able to directly open files via that path, but
>> showing that it can never read or write your mail is a rather different
>> matter.
>>
>
> Yes. Your use case is different than mine.
>
So.. your use case is what? If an AA user asked you to protect his mail
from his browser I'm sure you'd truthfully answer "no, we can't do that
but we can protect the path to your mail from your browser".. I think
not. One need only look at the wonderful marketing literature for AA to
see what you are telling people it can do, and your above statement
isn't consistent with that, sorry.
On 2007-06-21T20:16:25, Joshua Brindle <[email protected]> wrote:
> not. One need only look at the wonderful marketing literature for AA to
> see what you are telling people it can do, and your above statement
> isn't consistent with that, sorry.
I'm sorry. I don't work in marketing.
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
On Thu, 21 Jun 2007, Joshua Brindle wrote:
> Lars Marowsky-Bree wrote:
>> On 2007-06-21T16:59:54, Stephen Smalley <[email protected]> wrote:
>> <snip>
>>
>>
>> > Um, no. It might not be able to directly open files via that path, but
>> > showing that it can never read or write your mail is a rather different
>> > matter.
>> >
>>
>> Yes. Your use case is different than mine.
>>
>
> So.. your use case is what? If an AA user asked you to protect his mail from
> his browser I'm sure you'd truthfully answer "no, we can't do that but we can
> protect the path to your mail from your browser".. I think not. One need only
> look at the wonderful marketing literature for AA to see what you are telling
> people it can do, and your above statement isn't consistent with that, sorry.
remember, the policies define a white-list
so if a hacker wants to have mozilla access the mail files he needs to get
some other process on the sysstem to create a link or move a file to a
path that mozilla does have access to. until that is done there is no way
for mozilla to access the mail through the filesystem.
other programs could be run that would give mozilla access to the mail
contents, but it would be through some other path that the policy
permitted mozilla accessing in the first place.
David Lang
On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
> On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-21T15:42:28, James Morris <[email protected]> wrote:
> >
> > > > A veto is not a technical argument. All technical arguments (except for
> > > > "path name is ugly, yuk yuk!") have been addressed, have they not?
> > > AppArmor doesn't actually provide confinement, because it only operates on
> > > filesystem objects.
> > >
> > > What you define in AppArmor policy does _not_ reflect the actual
> > > confinement properties of the policy. Applications can simply use other
> > > mechanisms to access objects, and the policy is effectively meaningless.
> >
> > Only if they have access to another process which provides them with
> > that data.
>
> Or can access the data under a different path to which their profile
> does give them access, whether in its final destination or in some
> temporary file processed along the way.
>
> > And now, yes, I know AA doesn't mediate IPC or networking (yet), but
> > that's a missing feature, not broken by design.
>
> The incomplete mediation flows from the design, since the pathname-based
> mediation doesn't generalize to cover all objects unlike label- or
> attribute-based mediation. And the "use the natural abstraction for
> each object type" approach likewise doesn't yield any general model or
> anything that you can analyze systematically for data flow.
This feels quite a lot like a repeat of the discussion at the kernel
summit. There are valid uses for path based security, and if they don't
fit your needs, please don't use them. But, path based semantics alone
are not a valid reason to shut out AA.
-chris
On Thu, 21 Jun 2007, Chris Mason wrote:
> > The incomplete mediation flows from the design, since the pathname-based
> > mediation doesn't generalize to cover all objects unlike label- or
> > attribute-based mediation. And the "use the natural abstraction for
> > each object type" approach likewise doesn't yield any general model or
> > anything that you can analyze systematically for data flow.
>
> This feels quite a lot like a repeat of the discussion at the kernel
> summit. There are valid uses for path based security, and if they don't
> fit your needs, please don't use them. But, path based semantics alone
> are not a valid reason to shut out AA.
The validity or otherwise of pathname access control is not being
discussed here.
The point is that the pathname model does not generalize, and that
AppArmor's inability to provide adequate coverage of the system is a
design issue arising from this.
Recall that the question asked by Lars was whether there were any
outstanding technical issues relating to AppArmor.
AppArmor does not and can not provide the level of confinement claimed by
the documentation, and its policy does not reflect its actual confinement
properties. That's kind of a technical issue, right?
- James
--
James Morris
<[email protected]>
[email protected] wrote:
> On Thu, 21 Jun 2007, Joshua Brindle wrote:
>
>> Lars Marowsky-Bree wrote:
>>> On 2007-06-21T16:59:54, Stephen Smalley <[email protected]> wrote:
>>> <snip>
>>>
>>>
>>> > Um, no. It might not be able to directly open files via that
>>> path, but
>>> > showing that it can never read or write your mail is a rather
>>> different
>>> > matter.
>>> >
>>> Yes. Your use case is different than mine.
>>>
>>
>> So.. your use case is what? If an AA user asked you to protect his
>> mail from his browser I'm sure you'd truthfully answer "no, we can't
>> do that but we can protect the path to your mail from your browser"..
>> I think not. One need only look at the wonderful marketing literature
>> for AA to see what you are telling people it can do, and your above
>> statement isn't consistent with that, sorry.
>
> remember, the policies define a white-list
>
Except for unconfined processes.
> so if a hacker wants to have mozilla access the mail files he needs to
> get some other process on the sysstem to create a link or move a file
> to a path that mozilla does have access to. until that is done there
> is no way for mozilla to access the mail through the filesystem.
>
> other programs could be run that would give mozilla access to the mail
> contents, but it would be through some other path that the policy
> permitted mozilla accessing in the first place.
>
Or through IPC or the network, that is the point, filesystem only
coverage doesn't cut it; there is no way to say the browser can't access
the users mail in AA, and there never will be.
On Thu, 21 Jun 2007, Joshua Brindle wrote:
> [email protected] wrote:
>> On Thu, 21 Jun 2007, Joshua Brindle wrote:
>>
>> > Lars Marowsky-Bree wrote:
>> > > On 2007-06-21T16:59:54, Stephen Smalley <[email protected]> wrote:
>> > > <snip>
>> > >
>> > >
>> > > > Um, no. It might not be able to directly open files via that
>> > > path, but
>> > > > showing that it can never read or write your mail is a rather
>> > > different
>> > > > matter.
>> > > >
>> > > Yes. Your use case is different than mine.
>> > >
>> >
>> > So.. your use case is what? If an AA user asked you to protect his mail
>> > from his browser I'm sure you'd truthfully answer "no, we can't do that
>> > but we can protect the path to your mail from your browser".. I think
>> > not. One need only look at the wonderful marketing literature for AA to
>> > see what you are telling people it can do, and your above statement
>> > isn't consistent with that, sorry.
>>
>> remember, the policies define a white-list
>>
>
> Except for unconfined processes.
correct, but we are talking about what a confined process can get to
without assistance from an unconfined process.
>> so if a hacker wants to have mozilla access the mail files he needs to get
>> some other process on the sysstem to create a link or move a file to a
>> path that mozilla does have access to. until that is done there is no way
>> for mozilla to access the mail through the filesystem.
>>
>> other programs could be run that would give mozilla access to the mail
>> contents, but it would be through some other path that the policy
>> permitted mozilla accessing in the first place.
>>
> Or through IPC or the network, that is the point, filesystem only coverage
> doesn't cut it; there is no way to say the browser can't access the users
> mail in AA, and there never will be.
AA can be extended to cover these things in the future.
remember 'release early release often'?
how about 'perfect is the enemy of good enoug'?
at this point they're trying to get the initial implementation in so that
people can start takeing advantage of it. As a side effect the cost of
maintaining it will decrease, and they can put effort into planning future
enhancements.
besides, as far as the network communication goes, doesn't netfilter now
have a way to make rules for specific processes? if they don't then it
could be added, but the details of the implementation would probably be
very different from the current AA file controls.
how does delaying the acceptance of the current implementation encourage
the additional features being added?
but to answer your two comments.
how does mozilla access your mail over the network without first capturing
your password from somewhere?
as far as IPC goes, unix sockets are unavailable (AA as-is will control
them), so you must be talking about signals or shared memory as the IPC
mechanisms that mozilla would use to access your mail.
please explain to me what mail client you are useing that exposes your
mail via these mechinsms.
David Lang
James Morris wrote:
> On Thu, 21 Jun 2007, Chris Mason wrote:
>>> The incomplete mediation flows from the design, since the pathname-based
>>> mediation doesn't generalize to cover all objects unlike label- or
>>> attribute-based mediation. And the "use the natural abstraction for
>>> each object type" approach likewise doesn't yield any general model or
>>> anything that you can analyze systematically for data flow.
>>>
>> This feels quite a lot like a repeat of the discussion at the kernel
>> summit. There are valid uses for path based security, and if they don't
>> fit your needs, please don't use them. But, path based semantics alone
>> are not a valid reason to shut out AA.
>>
> The validity or otherwise of pathname access control is not being
> discussed here.
>
> The point is that the pathname model does not generalize, and that
> AppArmor's inability to provide adequate coverage of the system is a
> design issue arising from this.
>
The above two paragraphs appear to contradict each other.
> Recall that the question asked by Lars was whether there were any
> outstanding technical issues relating to AppArmor.
>
> AppArmor does not and can not provide the level of confinement claimed by
> the documentation, and its policy does not reflect its actual confinement
> properties. That's kind of a technical issue, right?
>
So if the document said "confinement with respect to direct file access
and POSIX.1e capabilities" and that list got extended as AA got new
confinement features, would that address your issue?
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor
On Thu, Jun 21, 2007 at 09:06:40PM -0400, James Morris wrote:
> On Thu, 21 Jun 2007, Chris Mason wrote:
>
> > > The incomplete mediation flows from the design, since the pathname-based
> > > mediation doesn't generalize to cover all objects unlike label- or
> > > attribute-based mediation. And the "use the natural abstraction for
> > > each object type" approach likewise doesn't yield any general model or
> > > anything that you can analyze systematically for data flow.
> >
> > This feels quite a lot like a repeat of the discussion at the kernel
> > summit. There are valid uses for path based security, and if they don't
> > fit your needs, please don't use them. But, path based semantics alone
> > are not a valid reason to shut out AA.
>
> The validity or otherwise of pathname access control is not being
> discussed here.
>
> The point is that the pathname model does not generalize, and that
> AppArmor's inability to provide adequate coverage of the system is a
> design issue arising from this.
>
As we have previously stated we are not using pathnames for IPC. The
use of pathnames for file access mediation is not a design issue that in
anyway prevents us from extending AppArmor to mediate IPC or networking.
The current focus is making the revision necessary for AppArmor's file
mediation at which point we can focus on finishing of the network
and IPC support.
> Recall that the question asked by Lars was whether there were any
> outstanding technical issues relating to AppArmor.
>
> AppArmor does not and can not provide the level of confinement claimed by
> the documentation, and its policy does not reflect its actual confinement
> properties. That's kind of a technical issue, right?
>
AppArmor currently controls file and capabilities, which was explicitly
stated in the documentation submitted with the patches. And it has
been posted before that network and IPC mediation are a wip.
On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
> On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-21T15:42:28, James Morris <[email protected]> wrote:
> >
>
> > And now, yes, I know AA doesn't mediate IPC or networking (yet), but
> > that's a missing feature, not broken by design.
>
> The incomplete mediation flows from the design, since the pathname-based
> mediation doesn't generalize to cover all objects unlike label- or
> attribute-based mediation. And the "use the natural abstraction for
> each object type" approach likewise doesn't yield any general model or
> anything that you can analyze systematically for data flow.
>
No the "incomplete" mediation does not flow from the design. We have
deliberately focused on doing the necessary modifications for pathname
based mediation. The IPC and network mediation are a wip.
We have never claimed to be using pathname-based mediation IPC or networking.
The "natural abstraction" approach does generize well enough and will
be analyzable.
> The emphasis on never modifying applications for security in AA likewise
> has an adverse impact here, as you will ultimately have to deal with
> application mediation of access to their own objects and operations not
> directly visible to the kernel (as we have already done in SELinux for
> D-BUS and others and are doing for X). Otherwise, your "protection" of
> desktop applications is easily subverted.
>
yes of course, we realize that dbus and X must be trusted applications,
this to will happen. But it will happen piece meal, something about
releasing early and often comes to mind.
> > > You might define this as a non-technical issue, but the fact that AppArmor
> > > simply does not and can not work is a fairly significant consideration, I
> > > would imagine.
> >
> > If I restrict my Mozilla to not access my on-disk mail folder, it can't
> > get there. (Barring bugs in programs which Mozilla is allowed to run
> > unconfined, sure.)
>
> Um, no. It might not be able to directly open files via that path, but
> showing that it can never read or write your mail is a rather different
> matter.
>
Actually it can be analyzed and shown. It is ugly to do and we
currently don't have a tool capable of doing it, but it is possible.
On Saturday 16 June 2007 02:20, Pavel Machek wrote:
> Ok, so mv gets slower for big trees... and open() gets faster for deep
> trees. Previously, open in current directory was one atomic read of
> directory entry, now it has to read directory, and its parent, and its
> parent parent, and its...
>
> (Or am I wrong and getting full path does not need to bring anything
> in, not even in cache-cold case?)
You are wrong, indeed. The dentries in the dcache are connected to the dcache
through their parent dentry pointers, which means that the parent dentries
are always in memory, too. No I/O is involved for walking up dentry trees.
(Caveat: nfsd does allow disconnected dentries. It does not make sense to try
confining an in-kernel daemon though, an no user process can ever access a
dentry before it gets connected (lookup does that), so this difference is
irrelevant here.)
On 2007-06-21T23:45:36, Joshua Brindle <[email protected]> wrote:
> >remember, the policies define a white-list
>
> Except for unconfined processes.
The argument that AA doesn't mediate what it is not configured to
mediate is correct, yes, but I don't think that's a valid _design_ issue
with AA.
> Or through IPC or the network, that is the point, filesystem only
> coverage doesn't cut it; there is no way to say the browser can't access
> the users mail in AA, and there never will be.
We have a variety of filtering mechanisms which are specific to a
domain. iptables filters networking only; file permissions filter file
access only. This argument is not really strong.
<tangent>
If you're now arguing the "spirit of Unix", I can turn your argument
around too: the Unix spirit is to have smallish dedicated tools. If AA
is dedicated to mediating file access, isn't that nice!
AA _could_ be extended to mediate network access and IPC (and this is
WIP). If we had tcpfs and ipcfs - you know, everything is a filesystem,
the Linux spirit! ;-) - AA could mediate them as well.
</tangent>
However, we're discussing the way it mediates file accesses here,
for which it appears useful and capable of functionality which SELinux's
approach cannot provide.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
On Thu, 2007-06-21 at 23:17 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-21T16:59:54, Stephen Smalley <[email protected]> wrote:
>
> > Or can access the data under a different path to which their profile
> > does give them access, whether in its final destination or in some
> > temporary file processed along the way.
>
> Well, yes. That is intentional.
>
> Your point is?
It may very well be unintentional access, especially when taking into
account wildcards in profiles and user-writable directories.
> > The emphasis on never modifying applications for security in AA likewise
> > has an adverse impact here, as you will ultimately have to deal with
> > application mediation of access to their own objects and operations not
> > directly visible to the kernel (as we have already done in SELinux for
> > D-BUS and others and are doing for X). Otherwise, your "protection" of
> > desktop applications is easily subverted.
>
> That is an interesting argument, but not what we're discussing here.
> We're arguing filesystem access mediation.
IOW, anything that AA cannot protect against is "out of scope". An easy
escape from any criticism.
> > Um, no. It might not be able to directly open files via that path, but
> > showing that it can never read or write your mail is a rather different
> > matter.
>
> Yes. Your use case is different than mine.
My use case is being able to protect data reliably. Yours?
--
Stephen Smalley
National Security Agency
On Friday June 22, [email protected] wrote:
> >
> > Yes. Your use case is different than mine.
>
> My use case is being able to protect data reliably. Yours?
Saying "protect data" is nearly meaningless without a threat model.
I bet you don't try to protect data from a direct nuclear hit, or a
court order.
AA has a fairly clear threat model. It involves a flaw in a
program being used by an external agent to cause it to use
privileges it would not normally exercise to subvert privacy or
integrity.
I think this model matches a lot of real threats that real sysadmins
have real concerns about. I believe that the design of AA addresses
this model quite well.
What is your threat model? Maybe it is just different.
NeilBrown
On 2007-06-22T07:19:39, Stephen Smalley <[email protected]> wrote:
> > > Or can access the data under a different path to which their profile
> > > does give them access, whether in its final destination or in some
> > > temporary file processed along the way.
> > Well, yes. That is intentional.
> >
> > Your point is?
>
> It may very well be unintentional access, especially when taking into
> account wildcards in profiles and user-writable directories.
Again, you're saying that AA is not confining unconfined processes.
That's a given. If unconfined processes assist confined processes in
breeching their confinement, yes, that is not mediated.
You're basically saying that anything but system-wide mandatory access
control is pointless.
If you want to go down that route, what is your reply to me saying that
SELinux cannot mediate NFS mounts - if the server is not confined using
SELinux as well? The argument is really, really moot and pointless. Yes,
unconfined actions can affect confined processes.
That's generally true for _any_ security system.
> > That is an interesting argument, but not what we're discussing here.
> > We're arguing filesystem access mediation.
> IOW, anything that AA cannot protect against is "out of scope". An easy
> escape from any criticism.
I'm quite sure that this reply is not AA specific as you try to make it
appear.
> > Yes. Your use case is different than mine.
> My use case is being able to protect data reliably. Yours?
I want to restrict certain possibly untrusted applications and
network-facing services from accessing certain file patterns, because as
a user and admin, that's the mindset I'm used to. I might be interested
in mediating other channels too, but the files are what I really care
about. I'm inclined to trust the other processes.
Your use case mandates complete system-wide mediation, because you want
full data flow analysis. Mine doesn't.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
On Fri, 2007-06-22 at 21:34 +1000, Neil Brown wrote:
> On Friday June 22, [email protected] wrote:
> > >
> > > Yes. Your use case is different than mine.
> >
> > My use case is being able to protect data reliably. Yours?
>
> Saying "protect data" is nearly meaningless without a threat model.
> I bet you don't try to protect data from a direct nuclear hit, or a
> court order.
>
>
> AA has a fairly clear threat model. It involves a flaw in a
> program being used by an external agent to cause it to use
> privileges it would not normally exercise to subvert privacy or
> integrity.
> I think this model matches a lot of real threats that real sysadmins
> have real concerns about. I believe that the design of AA addresses
> this model quite well.
>
>
> What is your threat model? Maybe it is just different.
The threat "model" you describe above is a subset of what SELinux
addresses. And our argument is that AA does not meet that model well,
because it relies upon ambiguous and unstable identifiers for subjects
and objects (a violation of the fundamental requirements for access
control) and because it provides very incomplete mediation.
>From http://www.nsa.gov/selinux/info/faq.cfm:
The Security-enhanced Linux's new features are designed to enforce the
separation of information based on confidentiality and integrity
requirements. They are designed for preventing processes from reading
data and programs, tampering with data and programs, bypassing
application security mechanisms, executing untrustworthy programs, or
interfering with other processes in violation of the system security
policy. They also help to confine the potential damage that can be
caused by malicious or flawed programs. They should also be useful for
enabling a single system to be used by users with differing security
authorizations to access multiple kinds of information with differing
security requirements without compromising those security requirements.
--
Stephen Smalley
National Security Agency
On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote:
> On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
> > On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> > > On 2007-06-21T15:42:28, James Morris <[email protected]> wrote:
> > >
> >
> > > And now, yes, I know AA doesn't mediate IPC or networking (yet), but
> > > that's a missing feature, not broken by design.
> >
> > The incomplete mediation flows from the design, since the pathname-based
> > mediation doesn't generalize to cover all objects unlike label- or
> > attribute-based mediation. And the "use the natural abstraction for
> > each object type" approach likewise doesn't yield any general model or
> > anything that you can analyze systematically for data flow.
> >
> No the "incomplete" mediation does not flow from the design. We have
> deliberately focused on doing the necessary modifications for pathname
> based mediation. The IPC and network mediation are a wip.
The fact that you have to go back to the drawing board for them is that
you didn't get the abstraction right in the first place.
> We have never claimed to be using pathname-based mediation IPC or networking.
> The "natural abstraction" approach does generize well enough and will
> be analyzable.
I think we must have different understandings of the words "generalize"
and "analyzable". Look, if I want to be able to state properties about
data flow in the system for confidentiality or integrity goals (my
secret data can never leak to unauthorized entities, my critical data
can never be corrupted/tainted by unauthorized entities - directly or
indirectly), then I need to be able to have a common reference point for
my policy. When my policy is based on different abstractions
(pathnames, IP addresses, window ids, whatever) for different objects,
then I can no longer identify how data can flow throughout the system in
a system-wide way.
> > Um, no. It might not be able to directly open files via that path, but
> > showing that it can never read or write your mail is a rather different
> > matter.
> >
> Actually it can be analyzed and shown. It is ugly to do and we
> currently don't have a tool capable of doing it, but it is possible.
No, it isn't possible when using ambiguous and unstable identifiers for
the subjects and objects, nor when mediation is incomplete.
--
Stephen Smalley
National Security Agency
On Thu, 2007-06-21 at 22:17 -0600, Crispin Cowan wrote:
> James Morris wrote:
> > On Thu, 21 Jun 2007, Chris Mason wrote:
> >>> The incomplete mediation flows from the design, since the pathname-based
> >>> mediation doesn't generalize to cover all objects unlike label- or
> >>> attribute-based mediation. And the "use the natural abstraction for
> >>> each object type" approach likewise doesn't yield any general model or
> >>> anything that you can analyze systematically for data flow.
> >>>
> >> This feels quite a lot like a repeat of the discussion at the kernel
> >> summit. There are valid uses for path based security, and if they don't
> >> fit your needs, please don't use them. But, path based semantics alone
> >> are not a valid reason to shut out AA.
> >>
> > The validity or otherwise of pathname access control is not being
> > discussed here.
> >
> > The point is that the pathname model does not generalize, and that
> > AppArmor's inability to provide adequate coverage of the system is a
> > design issue arising from this.
> >
> The above two paragraphs appear to contradict each other.
>
> > Recall that the question asked by Lars was whether there were any
> > outstanding technical issues relating to AppArmor.
> >
> > AppArmor does not and can not provide the level of confinement claimed by
> > the documentation, and its policy does not reflect its actual confinement
> > properties. That's kind of a technical issue, right?
> >
> So if the document said "confinement with respect to direct file access
> and POSIX.1e capabilities" and that list got extended as AA got new
> confinement features, would that address your issue?
That would certainly help, although one might quibble with the use of
the word "confinement" at all wrt AppArmor (it has a long-established
technical meaning that implies information flow control, and that goes
beyond even complete mediation - it requires global and persistent
protection of the data based on its properties, which requires stable
and unambiguous identifiers).
--
Stephen Smalley
National Security Agency
On Thu, Jun 21, 2007 at 09:06:40PM -0400, James Morris wrote:
> On Thu, 21 Jun 2007, Chris Mason wrote:
>
> > > The incomplete mediation flows from the design, since the pathname-based
> > > mediation doesn't generalize to cover all objects unlike label- or
> > > attribute-based mediation. And the "use the natural abstraction for
> > > each object type" approach likewise doesn't yield any general model or
> > > anything that you can analyze systematically for data flow.
> >
> > This feels quite a lot like a repeat of the discussion at the kernel
> > summit. There are valid uses for path based security, and if they don't
> > fit your needs, please don't use them. But, path based semantics alone
> > are not a valid reason to shut out AA.
>
> The validity or otherwise of pathname access control is not being
> discussed here.
>
> The point is that the pathname model does not generalize, and that
> AppArmor's inability to provide adequate coverage of the system is a
> design issue arising from this.
I'm sorry, but I don't see where in the paragraphs above you aren't
making a general argument against the pathname model.
-chris
On Fri, 2007-06-22 at 13:37 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-22T07:19:39, Stephen Smalley <[email protected]> wrote:
>
> > > > Or can access the data under a different path to which their profile
> > > > does give them access, whether in its final destination or in some
> > > > temporary file processed along the way.
> > > Well, yes. That is intentional.
> > >
> > > Your point is?
> >
> > It may very well be unintentional access, especially when taking into
> > account wildcards in profiles and user-writable directories.
>
> Again, you're saying that AA is not confining unconfined processes.
> That's a given. If unconfined processes assist confined processes in
> breeching their confinement, yes, that is not mediated.
The issue arises even for a collection of collaborating confined
processes with different profiles, and the collaboration may be
intentional or unintentional (in the latter case, one of the confined
processes may be taking advantage of known behavior of another process
and shared access by both to some resource in order to induce a
particular behavior in that process).
And remember that confinement isn't just about limiting untrusted
processes but also about protecting trusted processes; limiting the
inputs and outputs of a trusted process can be just as important to
preventing exploitation.
> You're basically saying that anything but system-wide mandatory access
> control is pointless.
Mandatory access control as historically understood has always meant
system-wide. As well as always being based on the security properties
of the data (so that global and persistent protection of the data is
possible). You can't actually use the terms 'mandatory access control'
or 'confinement' for AppArmor unless you redefine them.
> If you want to go down that route, what is your reply to me saying that
> SELinux cannot mediate NFS mounts - if the server is not confined using
> SELinux as well? The argument is really, really moot and pointless. Yes,
> unconfined actions can affect confined processes.
Sorry, do you mean the "server" as in the "server system" or as in the
"server daemon"? For the former, I'd agree - we would want SELinux
policy applied on the server as well as the client to ensure that the
data is being protected consistently throughout and that the server is
not misrepresenting the security guarantees expected by the clients.
Providing an illusion of confinement on each client without any
corresponding protection on the server system would be very prone to
bypass. For the latter, the kernel can only truly confine application
code, not in-kernel threads, although we can subject the in-kernel nfsd
to permission checking as a robustness check. We've always noted that
SELinux does depend on the correctness of the kernel.
> > > That is an interesting argument, but not what we're discussing here.
> > > We're arguing filesystem access mediation.
> > IOW, anything that AA cannot protect against is "out of scope". An easy
> > escape from any criticism.
>
> I'm quite sure that this reply is not AA specific as you try to make it
> appear.
Every time we've noted an issue with AA, the answer has been that it is
out of scope. Yet the public documentation for AA misrepresents the
situation and its comparisons with SELinux conveniently ignore its
limitations.
> > > Yes. Your use case is different than mine.
> > My use case is being able to protect data reliably. Yours?
>
> I want to restrict certain possibly untrusted applications and
> network-facing services from accessing certain file patterns, because as
> a user and admin, that's the mindset I'm used to. I might be interested
> in mediating other channels too, but the files are what I really care
> about. I'm inclined to trust the other processes.
>
> Your use case mandates complete system-wide mediation, because you want
> full data flow analysis. Mine doesn't.
Then yours isn't mandatory access control, nor is it confinement.
--
Stephen Smalley
National Security Agency
On 2007-06-22T07:53:47, Stephen Smalley <[email protected]> wrote:
> > No the "incomplete" mediation does not flow from the design. We have
> > deliberately focused on doing the necessary modifications for pathname
> > based mediation. The IPC and network mediation are a wip.
> The fact that you have to go back to the drawing board for them is that
> you didn't get the abstraction right in the first place.
That's an interesting claim, however I don't think it holds. AA was
designed to mediate file access in a form which is intuitive to admins.
It's to be expected that it doesn't directly apply to mediating other
forms of access.
> I think we must have different understandings of the words "generalize"
> and "analyzable". Look, if I want to be able to state properties about
> data flow in the system for confidentiality or integrity goals (my
> secret data can never leak to unauthorized entities, my critical data
> can never be corrupted/tainted by unauthorized entities - directly or
> indirectly),
I seem to think that this is not what AA is trying to do, so evaluating
it in that context doesn't seem useful. It's like saying a screw driver
isn't a hammer, so it is useless because you have a nail.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
On Fri, 2007-06-22 at 14:42 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-22T07:53:47, Stephen Smalley <[email protected]> wrote:
>
> > > No the "incomplete" mediation does not flow from the design. We have
> > > deliberately focused on doing the necessary modifications for pathname
> > > based mediation. The IPC and network mediation are a wip.
> > The fact that you have to go back to the drawing board for them is that
> > you didn't get the abstraction right in the first place.
>
> That's an interesting claim, however I don't think it holds. AA was
> designed to mediate file access in a form which is intuitive to admins.
>
> It's to be expected that it doesn't directly apply to mediating other
> forms of access.
>
> > I think we must have different understandings of the words "generalize"
> > and "analyzable". Look, if I want to be able to state properties about
> > data flow in the system for confidentiality or integrity goals (my
> > secret data can never leak to unauthorized entities, my critical data
> > can never be corrupted/tainted by unauthorized entities - directly or
> > indirectly),
>
> I seem to think that this is not what AA is trying to do, so evaluating
> it in that context doesn't seem useful. It's like saying a screw driver
> isn't a hammer, so it is useless because you have a nail.
Again, in that case, please remove all uses of the terms "mandatory
access control", "confinement" and "integrity protection" from AA
documentation and code.
--
Stephen Smalley
National Security Agency
On 2007-06-22T08:41:51, Stephen Smalley <[email protected]> wrote:
> The issue arises even for a collection of collaborating confined
> processes with different profiles, and the collaboration may be
> intentional or unintentional (in the latter case, one of the confined
> processes may be taking advantage of known behavior of another process
> and shared access by both to some resource in order to induce a
> particular behavior in that process).
Point taken; the point remains is that you need at least several
(intentionally or not) cooperating processes. The chances of this are
significantly lower than a single process exploit.
> And remember that confinement isn't just about limiting untrusted
> processes but also about protecting trusted processes; limiting the
> inputs and outputs of a trusted process can be just as important to
> preventing exploitation.
True. It'd appear that if you want that, you'd specify the AA profile so
that it doesn't include directories/files writable by untrusted
processes.
> Sorry, do you mean the "server" as in the "server system" or as in the
> "server daemon"? For the former, I'd agree - we would want SELinux
> policy applied on the server as well as the client to ensure that the
> data is being protected consistently throughout and that the server is
> not misrepresenting the security guarantees expected by the clients.
> Providing an illusion of confinement on each client without any
> corresponding protection on the server system would be very prone to
> bypass. For the latter, the kernel can only truly confine application
> code, not in-kernel threads, although we can subject the in-kernel nfsd
> to permission checking as a robustness check. We've always noted that
> SELinux does depend on the correctness of the kernel.
Oh, you're saying that this threat is out-of-scope? ;-)
> Every time we've noted an issue with AA, the answer has been that it is
> out of scope. Yet the public documentation for AA misrepresents the
> situation and its comparisons with SELinux conveniently ignore its
> limitations.
I'm sorry. Again, I'm not responsible for marketing comparisons made by
anyone else, nor do I think they should apply to this discussion where
we're discussing the merits of what AA actually _does_; not what
someone's marketing claims it does - otherwise I'll go dig out marketing
claims about SELinux too ;-)
And, coming at it from that direction, I feel it does something useful.
Note that here we've already strayed from the focus of the discussion;
we're no longer arguing "the implementation is ugly/broken", but you're
claiming "doesn't do what I need" - which I'm not disagreeing with. It
doesn't do what you want. Which is why you have SELinux, and it's going
to stay. Fine.
If we assume that the users who run it do have a need / use case for it
which they can't solve differently, we should really get back to the
discussion of how those needs can be met or provided by Linux in a
feasible way.
> > Your use case mandates complete system-wide mediation, because you want
> > full data flow analysis. Mine doesn't.
> Then yours isn't mandatory access control, nor is it confinement.
I apologize for not using the word "confinement" in the way you expect
it to be used. I certainly don't want to imply it does do things it
doesn't. Keep in mind I'm not a native speaker, so nuances do get lost
sometimes; nor do I have long years of experience in the security
field. Thanks for clearing this up.
So agreed, it is not confinement nor MAC.
Would it be more appropriate if I used the word "restricts" or
"constrains"?
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-22T08:41:51, Stephen Smalley <[email protected]> wrote:
> > Sorry, do you mean the "server" as in the "server system" or as in the
> > "server daemon"? For the former, I'd agree - we would want SELinux
> > policy applied on the server as well as the client to ensure that the
> > data is being protected consistently throughout and that the server is
> > not misrepresenting the security guarantees expected by the clients.
> > Providing an illusion of confinement on each client without any
> > corresponding protection on the server system would be very prone to
> > bypass. For the latter, the kernel can only truly confine application
> > code, not in-kernel threads, although we can subject the in-kernel nfsd
> > to permission checking as a robustness check. We've always noted that
> > SELinux does depend on the correctness of the kernel.
>
> Oh, you're saying that this threat is out-of-scope? ;-)
Kernel flaws aren't something we can address (reliably and in general)
via a kernel mechanism. Versus a threat that can be addressed by kernel
mechanism, like providing complete mediation and unambiguous access
control. There is a difference. And we aren't ignoring the kernel
correctness problem - there is separate work in that space, but it
requires separate mechanism outside of SELinux itself.
> Note that here we've already strayed from the focus of the discussion;
> we're no longer arguing "the implementation is ugly/broken", but you're
> claiming "doesn't do what I need" - which I'm not disagreeing with. It
> doesn't do what you want. Which is why you have SELinux, and it's going
> to stay. Fine.
>
> If we assume that the users who run it do have a need / use case for it
> which they can't solve differently, we should really get back to the
> discussion of how those needs can be met or provided by Linux in a
> feasible way.
Part of the discussion has been whether those users' needs could be
solved better via SELinux, whether via improved userspace tools (ala
seedit possibly with an enhanced restorecond) or via extended kernel
mechanism (ala named type transitions and some kind of inheritance
model). It does however seem like there is a fundamental conflict there
on renaming behavior; I do not believe that file protections should
automatically change in the kernel upon rename and should require
explicit userspace action. The question though is whether that renaming
behavior in AA is truly a user requirement or a manufactured (i.e.
made-up) one, and whether it is truly a runtime requirement or just a
policy creation time one (the latter being adequately addressed by
userspace relabeling).
If that behavior is truly needed (a point I wouldn't concede), then the
discussion does reduce down to the right implementation method. There
it appears that the primary objection is to regenerating full pathname
strings and matching them versus some kind of incremental matching
either during lookup itself or via a reverse match as suggested. That
discussion is principally one in which the vfs folks should be engaged,
not me.
> > > Your use case mandates complete system-wide mediation, because you want
> > > full data flow analysis. Mine doesn't.
> > Then yours isn't mandatory access control, nor is it confinement.
>
> I apologize for not using the word "confinement" in the way you expect
> it to be used. I certainly don't want to imply it does do things it
> doesn't. Keep in mind I'm not a native speaker, so nuances do get lost
> sometimes; nor do I have long years of experience in the security
> field. Thanks for clearing this up.
>
> So agreed, it is not confinement nor MAC.
>
> Would it be more appropriate if I used the word "restricts" or
> "constrains"?
Yes. Or simply "controls file accesses and capability usage".
--
Stephen Smalley
National Security Agency
On Fri, 22 Jun 2007, Chris Mason wrote:
> > The validity or otherwise of pathname access control is not being
> > discussed here.
> >
> > The point is that the pathname model does not generalize, and that
> > AppArmor's inability to provide adequate coverage of the system is a
> > design issue arising from this.
>
> I'm sorry, but I don't see where in the paragraphs above you aren't
> making a general argument against the pathname model.
There are two distinct concepts here.
A. Pathname labeling - applying access control to pathnames to objects,
rather than labeling the objects themselves.
Think of this as, say, securing your house by putting a gate in the street
in front of the house, regardless of how many other possible paths there
are to the house via other streets, adjoining properties etc.
Pathname labeling and mediation is simply mediating a well-known path to
the object. In this analogy, object labeling would instead ensure that
all of the accessible doors, windows and other entrances of the house were
locked, so that someone trying to break in from the rear alley would
not get in simply by bypassing the front gate and opening any door.
What you do with AppArmor, instead of addressing the problem, is just
redefine the environment along the lines of "set your house into a rock
wall so there is only one path to it".
B. Pathname access control as a general abstraction for OS security.
Which is what was being discussed above, in response to a question from
Lars about technical issues, and that this _model_ doesn't generalize to
the rest of the OS, regardless of whether you think the mechanism of
pathname labeling itself is appropriate or not.
In any case, clarifying such a distinction should not obscure the central
issue, which is: AppArmor's design is broken.
General users, many kernel developers, and even security researchers who
have not yet looked under the covers [1], are probably unaware that the
confinement claims being made about AppArmor's confinement capabilities
are simply not possible with either its model or implementation.
To quote from:
http://www.novell.com/linux/security/apparmor/
"AppArmor gives you network application security via mandatory access
control for programs, protecting against the exploitation of software
flaws and compromised systems. AppArmor includes everything you need to
provide effective containment for programs (including those that run as
root) to thwart attempted exploits and even zero-day attacks."
This is not accurate in any sense of the term containment of mandatory
access control that I've previously encountered.
The fact that it doesn't work as expected does not arise simply from
missing features or being "different". It arises from the design of the
system, which uses a pathname abstraction, where, even if we agree to
ignore issue (1) above, still does not work, because only filesystem
interactions are mediated.
AppArmor policy does not reflect the behavior of the system.
The "simple" policy that users can so effortlessly manipulate is simple
because it is wrong, and deliberately so.
The design of the AppArmor is based on _appearing simple_, but at the
expense of completeness and thus correctness.
[1] http://lkml.org/lkml/2007/4/19/357
"My gosh, you're right. What the heck? With all due respect to the
developers of AppArmor, I can't help thinking that that's pretty lame.
I think this raises substantial questions about the value of AppArmor.
What is the point of having a jail if it leaves gaping holes that
malicious code could use to escape?
And why isn't this documented clearly, with the implications fully
explained?" - David Wagner, http://www.cs.berkeley.edu/~daw/
Indeed.
- James
--
James Morris
<[email protected]>
On Fri, Jun 22, 2007 at 09:48:12AM -0400, James Morris wrote:
> On Fri, 22 Jun 2007, Chris Mason wrote:
>
> > > The validity or otherwise of pathname access control is not being
> > > discussed here.
> > >
> > > The point is that the pathname model does not generalize, and that
> > > AppArmor's inability to provide adequate coverage of the system is a
> > > design issue arising from this.
> >
> > I'm sorry, but I don't see where in the paragraphs above you aren't
> > making a general argument against the pathname model.
>
> There are two distinct concepts here.
>
> A. Pathname labeling - applying access control to pathnames to objects,
> rather than labeling the objects themselves.
>
> Think of this as, say, securing your house by putting a gate in the street
> in front of the house, regardless of how many other possible paths there
> are to the house via other streets, adjoining properties etc.
>
> Pathname labeling and mediation is simply mediating a well-known path to
> the object. In this analogy, object labeling would instead ensure that
> all of the accessible doors, windows and other entrances of the house were
> locked, so that someone trying to break in from the rear alley would
> not get in simply by bypassing the front gate and opening any door.
>
> What you do with AppArmor, instead of addressing the problem, is just
> redefine the environment along the lines of "set your house into a rock
> wall so there is only one path to it".
>
>
> B. Pathname access control as a general abstraction for OS security.
>
> Which is what was being discussed above, in response to a question from
> Lars about technical issues, and that this _model_ doesn't generalize to
> the rest of the OS, regardless of whether you think the mechanism of
> pathname labeling itself is appropriate or not.
I'm sorry, but I don't see where in the paragraphs above you aren't
making a general argument against the pathname model. I'm not trying to
get into that discussion (I'm smart enough to know I'm far too stupid to
hold my own there).
I do understand that AA is different from selinux, and that you
have valid points about the level and type of protection that AA offers.
But, this is a completely different discussion than if AA is
solving problems in the wild for its intended audience, or if the code
is somehow flawed and breaking other parts of the kernel.
We've been over the "AA is different" discussion in threads about a
billion times, and at the last kernel summit. I think Lars and others
have done a pretty good job of describing the problems they are trying
to solve, can we please move on to discussing technical issues around
that?
-chris
On Fri, 22 Jun 2007, Chris Mason wrote:
> But, this is a completely different discussion than if AA is
> solving problems in the wild for its intended audience, or if the code
> is somehow flawed and breaking other parts of the kernel.
Is its intended audience aware of its limitiations? Lars has just
acknowledged that it does not implement mandatory access control, for one.
Until people understand these issues, they certainly need to be addressed
in the context of upstream merge.
> We've been over the "AA is different" discussion in threads about a
> billion times, and at the last kernel summit.
I don't believe that people at the summit were adequately informed on the
issue, and from several accounts I've heard, Stephen Smalley was
effectively cut off before he could even get to his second slide.
> I think Lars and others have done a pretty good job of describing the
> problems they are trying to solve, can we please move on to discussing
> technical issues around that?
Keep in mind that this current thread arose from Greg KH asking about
whether AppArmor could effectively be implemented via SELinux and
userspace labeling.
Some of us took the time to perform analysis and then provide feedback on
this, in good faith.
The underlying issues only came up again in response to an inflammatory
post by Lars. If you want to avoid discussions of AppArmor's design, then
I suggest taking it up with those who initiate them.
- James
--
James Morris
<[email protected]>
On Fri, 2007-06-22 at 09:22 -0400, Stephen Smalley wrote:
> On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-22T08:41:51, Stephen Smalley <[email protected]> wrote:
> > > Sorry, do you mean the "server" as in the "server system" or as in the
> > > "server daemon"? For the former, I'd agree - we would want SELinux
> > > policy applied on the server as well as the client to ensure that the
> > > data is being protected consistently throughout and that the server is
> > > not misrepresenting the security guarantees expected by the clients.
> > > Providing an illusion of confinement on each client without any
> > > corresponding protection on the server system would be very prone to
> > > bypass. For the latter, the kernel can only truly confine application
> > > code, not in-kernel threads, although we can subject the in-kernel nfsd
> > > to permission checking as a robustness check. We've always noted that
> > > SELinux does depend on the correctness of the kernel.
> >
> > Oh, you're saying that this threat is out-of-scope? ;-)
>
> Kernel flaws aren't something we can address (reliably and in general)
> via a kernel mechanism. Versus a threat that can be addressed by kernel
> mechanism, like providing complete mediation and unambiguous access
> control. There is a difference. And we aren't ignoring the kernel
> correctness problem - there is separate work in that space, but it
> requires separate mechanism outside of SELinux itself.
>
> > Note that here we've already strayed from the focus of the discussion;
> > we're no longer arguing "the implementation is ugly/broken", but you're
> > claiming "doesn't do what I need" - which I'm not disagreeing with. It
> > doesn't do what you want. Which is why you have SELinux, and it's going
> > to stay. Fine.
> >
> > If we assume that the users who run it do have a need / use case for it
> > which they can't solve differently, we should really get back to the
> > discussion of how those needs can be met or provided by Linux in a
> > feasible way.
>
> Part of the discussion has been whether those users' needs could be
> solved better via SELinux, whether via improved userspace tools (ala
> seedit possibly with an enhanced restorecond) or via extended kernel
> mechanism (ala named type transitions and some kind of inheritance
> model). It does however seem like there is a fundamental conflict there
> on renaming behavior; I do not believe that file protections should
> automatically change in the kernel upon rename and should require
> explicit userspace action. The question though is whether that renaming
> behavior in AA is truly a user requirement or a manufactured (i.e.
> made-up) one, and whether it is truly a runtime requirement or just a
> policy creation time one (the latter being adequately addressed by
> userspace relabeling).
I suppose there is also a question of whether that kind of model
wouldn't be better implemented as an ACL model with implicit
inheritance, e.g. if you specify an ACL on a directory, then all files
accessed via that directory are controlled in accordance with that ACL
unless they have their own more specific ACL, and if you move one of
those files to a different directory, then they automatically pick up
the protection of the new parent. Doesn't require the kernel to be
matching pathname strings, just walking up the tree to determine the
closest ancestor with an explicit ACL on it.
>
> If that behavior is truly needed (a point I wouldn't concede), then the
> discussion does reduce down to the right implementation method. There
> it appears that the primary objection is to regenerating full pathname
> strings and matching them versus some kind of incremental matching
> either during lookup itself or via a reverse match as suggested. That
> discussion is principally one in which the vfs folks should be engaged,
> not me.
>
> > > > Your use case mandates complete system-wide mediation, because you want
> > > > full data flow analysis. Mine doesn't.
> > > Then yours isn't mandatory access control, nor is it confinement.
> >
> > I apologize for not using the word "confinement" in the way you expect
> > it to be used. I certainly don't want to imply it does do things it
> > doesn't. Keep in mind I'm not a native speaker, so nuances do get lost
> > sometimes; nor do I have long years of experience in the security
> > field. Thanks for clearing this up.
> >
> > So agreed, it is not confinement nor MAC.
> >
> > Would it be more appropriate if I used the word "restricts" or
> > "constrains"?
>
> Yes. Or simply "controls file accesses and capability usage".
>
--
Stephen Smalley
National Security Agency
--- Stephen Smalley <[email protected]> wrote:
> Mandatory access control as historically understood has always meant
> system-wide.
Chapter and verse: TCSEC 3.1.1.4 Mandatory Access Control
"The TCB shall enforce a mandatory access control policy over
all subjects and storage objects under its control."
Chapter and verse: TCSEC 3.2.1.4 Mandatory Access Control
"The TCB shall enforce a mandatory access control policy over
all resources that are directly or indirectly accessible by
subjects external to the TCB."
The first reference is in the definition of a B1 system, while the
second is for a B2 system. It was made clear to those of us
doing TCSEC evaluations that there is a very real distintion between
these two requirements. In the history that I've been through,
starting in 1987, the B1 requirement has been read to allow for
things that are not storage objects to be uncontrolled while the
B2 requirement does not. If everything is a storage object, which
is the approach everybody took, yes, you're looking at system wide.
If, on the other hand, you were to take a different model approach
and say that networking does not use storage objects you would not
have to account for them under the B1 rules, while you would still
have to for B2. Historically, no one succeeded with B2, and the
mindset of B1 prevailed. So, historically, the understanding was
that it was easier to declare everything a storage object and code
up some MAC for it than it was to provide a security model that
explained networking as it really works. I suggest that if AA wants
to declare that as far as they are concerned sockets, ports, and
packets are none of them storage objects but are instead pregnant
weasels that is their peragotive as system designers and that
a B1 evaluation team would have accepted that, provided sufficient
evidence and explaination of the relevence of pregnant weasels
was provided. It would not have worked at B2, but historically
everyone understood that B2 was out of reach.
Stephen is correct in that historically everyone implemented system
that put everything under MAC, but is not in that it was well
understood that if you could define something as not being a
storage object you didn't have to submit it to MAC. Then as now
it was easier to get people to code MAC than to get them to write
papers about the security properties of pregnant weasels.
Casey Schaufler
[email protected]
On Fri, Jun 22, 2007 at 10:23:03AM -0400, James Morris wrote:
> On Fri, 22 Jun 2007, Chris Mason wrote:
>
> > But, this is a completely different discussion than if AA is
> > solving problems in the wild for its intended audience, or if the code
> > is somehow flawed and breaking other parts of the kernel.
>
> Is its intended audience aware of its limitiations? Lars has just
> acknowledged that it does not implement mandatory access control, for one.
>
> Until people understand these issues, they certainly need to be addressed
> in the context of upstream merge.
It is definitely useful to clearly understand the intended AA use cases
during the merge.
>
> > We've been over the "AA is different" discussion in threads about a
> > billion times, and at the last kernel summit.
>
> I don't believe that people at the summit were adequately informed on the
> issue, and from several accounts I've heard, Stephen Smalley was
> effectively cut off before he could even get to his second slide.
I'm sure people there will have a different versions of events. The
one part that was discussed was if pathname based security was
useful, and a number of the people in the room (outside of
novell) said it was. Now, it could be that nobody wanted to argue
anymore, since most opinions had come out on one list or another by
then.
But as someone who doesn't use either SElinux or AA, I really hope
we can get past the part of the debate where:
while(1)
AA) we think we're making users happy with pathname security
SELINUX) pathname security sucks
So, yes Greg got it started and Lars is a well known trouble maker, and
I completely understand if you want to say no thank you to an selinux
based AA ;) The models are different and it shouldn't be a requirement
that they try to use the same underlying mechanisms.
-chris
On Fri, 22 Jun 2007, James Morris wrote:
> On Fri, 22 Jun 2007, Chris Mason wrote:
>
>> But, this is a completely different discussion than if AA is
>> solving problems in the wild for its intended audience, or if the code
>> is somehow flawed and breaking other parts of the kernel.
>
> Is its intended audience aware of its limitiations? Lars has just
> acknowledged that it does not implement mandatory access control, for one.
>
> Until people understand these issues, they certainly need to be addressed
> in the context of upstream merge.
there are always going to be people who misunderstand things. by this
logic nothing can ever be merged that can be misused.
at least some of the intended audience (including me) do understand the
limits and still consider the result useful.
David Lang
On Fri, 22 Jun 2007, Stephen Smalley wrote:
> On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote:
>> On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
>>> On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
>>>> On 2007-06-21T15:42:28, James Morris <[email protected]> wrote:
>>>>
>>>
>>>> And now, yes, I know AA doesn't mediate IPC or networking (yet), but
>>>> that's a missing feature, not broken by design.
>>>
>>> The incomplete mediation flows from the design, since the pathname-based
>>> mediation doesn't generalize to cover all objects unlike label- or
>>> attribute-based mediation. And the "use the natural abstraction for
>>> each object type" approach likewise doesn't yield any general model or
>>> anything that you can analyze systematically for data flow.
>>>
>> No the "incomplete" mediation does not flow from the design. We have
>> deliberately focused on doing the necessary modifications for pathname
>> based mediation. The IPC and network mediation are a wip.
>
> The fact that you have to go back to the drawing board for them is that
> you didn't get the abstraction right in the first place.
or it just means that the tool to regulat the network is different from
the tool to regulate the filesystem.
oh, by the way. that's how the rest of the *nix world works. firewall
rules apply to networking, filesystem permissions and ACLs apply to the
filesystem.
this is like climing that the latest improvement to ipsec shouldn't go in
becouse it down't allow you to handle things the same way that you handle
temp files or a serial port.
>> We have never claimed to be using pathname-based mediation IPC or networking.
>> The "natural abstraction" approach does generize well enough and will
>> be analyzable.
>
> I think we must have different understandings of the words "generalize"
> and "analyzable". Look, if I want to be able to state properties about
> data flow in the system for confidentiality or integrity goals (my
> secret data can never leak to unauthorized entities, my critical data
> can never be corrupted/tainted by unauthorized entities - directly or
> indirectly), then I need to be able to have a common reference point for
> my policy. When my policy is based on different abstractions
> (pathnames, IP addresses, window ids, whatever) for different objects,
> then I can no longer identify how data can flow throughout the system in
> a system-wide way.
if you are doing a system-wide analysis then you are correct.
the AA approach is to start with the exposed items and limit the damage
that can be done to you.
sysadmins already think in terms of paths and what can access that path
(directory permissions), AA extends this in a very natural way and doesn't
require any special tools or extra steps for normal administration. As a
result sysadmins are far more likely to use this then they are to touch
anything that requires that they do a full system analysis before they
start.
another advantage is that since the policies are independant of each other
it becomes very easy for software to include sample policies with the
source.
>>> Um, no. It might not be able to directly open files via that path, but
>>> showing that it can never read or write your mail is a rather different
>>> matter.
>>>
>> Actually it can be analyzed and shown. It is ugly to do and we
>> currently don't have a tool capable of doing it, but it is possible.
>
> No, it isn't possible when using ambiguous and unstable identifiers for
> the subjects and objects, nor when mediation is incomplete.
it is possible to say that without assistance from an outside process the
process cannot access the files containing your mail.
if there is some other method of accessing the content no filesystem-level
thing can know about it (for example, if another process is a pop server
that requires no password). but I don't beleive that SELinux policies as
distributed by any vendor would prevent this (yes, it would be possible
for a tailored policy to prevent it, but if the policy is so complex that
only distro staff should touch it that doesn't matter in real life)
David Lang
* Chris Mason ([email protected]) wrote:
> I'm sure people there will have a different versions of events. The
> one part that was discussed was if pathname based security was
> useful, and a number of the people in the room (outside of
> novell) said it was. Now, it could be that nobody wanted to argue
> anymore, since most opinions had come out on one list or another by
> then.
Indeed. The trouble is that's too high level compared with the actual
implementation details. AA is stalled because it has failed to get
VFS support for it's model. I don't see a nice way out unless it
changes it's notion of policy language (globbing is the tough one)
or gets traction to pass dentry/vfsmount all the way down. Paths are
completely relevant for security, esp. when considering the parent dir
and the leaf (as in forward lookup case). Retroactively creating the
full path is at the minimum ugly, and in the worst case can be insecure
(yes AA has taken many measures to mitigate that insecurity).
> But as someone who doesn't use either SElinux or AA, I really hope
> we can get past the part of the debate where:
>
> while(1)
> AA) we think we're making users happy with pathname security
> SELINUX) pathname security sucks
Yes. Please. Both parties are miserably failing the sanity test.
Doing the same thing over and over and expecting different results.
AA folks: deal with the VFS issues that your patchset have in a palatable
way (which does not include passing NULL when it's inconvenient to
do otherwise). You've already missed an opportunity with Christoph's
suggestions for changes in NFS. I know you've considered many alternative
approaches and consistently hit dead ends. But please note, if you
have coded yourself into a corner because of your policy language,
that's your issue to solve, not ours.
SELinux folks: do something useful rather than quibbling over the TCSEC
definition of MAC and AA's poor taste in marketing literature. Here's
some suggestions:
1) Make SELinux usable (it's *still* the number one complaint). While
this is a bit of a cheap shot, it really is one of the core reasons AA
advocates exist.
2) Work on a variant of Kyle's suggestion to squash the relevancy of AA.
3) Write an effective exploit against AA that demonstrates the fundamental
weakness of the model (better make sure it's not also an issue for
targetted policy).
thanks,
-chris
This thread is amazing. With so many smart people's precious time,
What are the results?
What are the issues anyway?
Is anyone happy? (I'm not and I assume Chris is not)
Yes, "waste of time" is taking place here, but
it's not for "pathname-based MAC" but for "wrongly posted messages",
I believe. I'm a relatively new to this ml, let me ask.
Is this ml a place of judge or battle? (not to help or support?)
Nothing is perfect, so we can work to make things to better, right?
I have suggestions:
Let's clarify issues first.
- problems (or limitations) of pathname-based MAC
- advantages of pathname-based MAC
- how can pathname-based MAC supplement label based
(Stephen, James and Kyle, please help)
Let's start the arguments again if we get the issues.
Threads should be definitely separated per issue and
a assigning a chair may help.
Above issues are independent of SELinux. We should not *compare*
SELinux and AA, that can cause a problem. Every software has
shortages that's why we need to work and we can make progress.
For some issues we may need to compare them, in that case
moderators would help.
BTW I have posted a RFC of TOMOYO Linux that is another
pathname-based MAC.
http://lkml.org/lkml/2007/6/13/58
AA and TOMOYO Linux have BoF sessions at OLS2007,
so it would be a great opportunity to *talk* over the issues.
What I want to say is "let's make progress and help each other
to make Linux better".
Thank you,
Toshiharu Harada
Chris Wright wrote:
> * Chris Mason ([email protected]) wrote:
>> I'm sure people there will have a different versions of events. The
>> one part that was discussed was if pathname based security was
>> useful, and a number of the people in the room (outside of
>> novell) said it was. Now, it could be that nobody wanted to argue
>> anymore, since most opinions had come out on one list or another by
>> then.
>
> Indeed. The trouble is that's too high level compared with the actual
> implementation details. AA is stalled because it has failed to get
> VFS support for it's model. I don't see a nice way out unless it
> changes it's notion of policy language (globbing is the tough one)
> or gets traction to pass dentry/vfsmount all the way down. Paths are
> completely relevant for security, esp. when considering the parent dir
> and the leaf (as in forward lookup case). Retroactively creating the
> full path is at the minimum ugly, and in the worst case can be insecure
> (yes AA has taken many measures to mitigate that insecurity).
>
>> But as someone who doesn't use either SElinux or AA, I really hope
>> we can get past the part of the debate where:
>>
>> while(1)
>> AA) we think we're making users happy with pathname security
>> SELINUX) pathname security sucks
>
> Yes. Please. Both parties are miserably failing the sanity test.
> Doing the same thing over and over and expecting different results.
>
> AA folks: deal with the VFS issues that your patchset have in a palatable
> way (which does not include passing NULL when it's inconvenient to
> do otherwise). You've already missed an opportunity with Christoph's
> suggestions for changes in NFS. I know you've considered many alternative
> approaches and consistently hit dead ends. But please note, if you
> have coded yourself into a corner because of your policy language,
> that's your issue to solve, not ours.
>
> SELinux folks: do something useful rather than quibbling over the TCSEC
> definition of MAC and AA's poor taste in marketing literature. Here's
> some suggestions:
>
> 1) Make SELinux usable (it's *still* the number one complaint). While
> this is a bit of a cheap shot, it really is one of the core reasons AA
> advocates exist.
> 2) Work on a variant of Kyle's suggestion to squash the relevancy of AA.
> 3) Write an effective exploit against AA that demonstrates the fundamental
> weakness of the model (better make sure it's not also an issue for
> targetted policy).
--
Toshiharu Harada
[email protected]
> This thread is amazing. With so many smart people's precious time,
>
> What are the results?
> What are the issues anyway?
> Is anyone happy? (I'm not and I assume Chris is not)
>
> Yes, "waste of time" is taking place here, but
> it's not for "pathname-based MAC" but for "wrongly posted messages",
> I believe. I'm a relatively new to this ml, let me ask.
>
> Is this ml a place of judge or battle? (not to help or support?)
>
> Nothing is perfect, so we can work to make things to better, right?
> I have suggestions:
>
> Let's clarify issues first.
> - problems (or limitations) of pathname-based MAC
> - advantages of pathname-based MAC
> - how can pathname-based MAC supplement label based
> (Stephen, James and Kyle, please help)
>
> Let's start the arguments again if we get the issues.
> Threads should be definitely separated per issue and
> a assigning a chair may help.
Well, I crated a Wiki page. If it helps, please
feel free to use it. I mean I would like
people to add your issues here. It's wiki, so
you are welcome to modify everything.
http://tomoyo.sourceforge.jp/wiki-e/?MAC-ISSUES
If ml is better, I have no objections.
I just wanted to help discussion.
> Above issues are independent of SELinux. We should not *compare*
> SELinux and AA, that can cause a problem. Every software has
> shortages that's why we need to work and we can make progress.
> For some issues we may need to compare them, in that case
> moderators would help.
>
> BTW I have posted a RFC of TOMOYO Linux that is another
> pathname-based MAC.
> http://lkml.org/lkml/2007/6/13/58
> AA and TOMOYO Linux have BoF sessions at OLS2007,
> so it would be a great opportunity to *talk* over the issues.
>
> What I want to say is "let's make progress and help each other
> to make Linux better".
Cheers,
Toshiharu Harada
Stephen Smalley wrote:
>On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
>> And now, yes, I know AA doesn't mediate IPC or networking (yet), but
>> that's a missing feature, not broken by design.
>
>The incomplete mediation flows from the design, since the pathname-based
>mediation doesn't generalize to cover all objects unlike label- or
>attribute-based mediation.
I don't see anything in the AA design that would prevent an extending
it to mediate network and IPC while remaining consistent with its design
so far. Do you? It seems to me the AA design is to mediate filesystem
access using pathname-based access control, and that says nothing about
how they mediate network access.
I have built sandboxing tools before, and my experience is that the
filesystem mediation is the hardest, gronkiest part. In comparison,
mediating networking and IPC is considerably easier. The policy
language for mediating access to the network can be pretty simple.
The same for IPC. Obviously you shouldn't expect the policy language
for networking to use filenames, any more than you should expect the
policy languages for filesystems to use TCP/IP port numbers; that wouldn't
make any sense.
>And the "use the natural abstraction for
>each object type" approach likewise doesn't yield any general model or
>anything that you can analyze systematically for data flow.
I don't see this as relevant to whether AA should be merged.
Fight that one in the marketplace for users, not L-K.
>> If I restrict my Mozilla to not access my on-disk mail folder, it can't
>> get there. (Barring bugs in programs which Mozilla is allowed to run
>> unconfined, sure.)
>
>Um, no. It might not be able to directly open files via that path, but
>showing that it can never read or write your mail is a rather different
>matter.
"Showing that it can never read or write your mail" is not part of AA's
goals. People whose goals differ from AA's can use a different tool.
No one is forcing you to use AA if it isn't useful to you.
I don't see this criticism as relevant to a merger decision.
Hi!
> But as someone who doesn't use either SElinux or AA, I really hope
> we can get past the part of the debate where:
>
> while(1)
> AA) we think we're making users happy with pathname security
> SELINUX) pathname security sucks
(Hopefully I'll not be fired for this. :-)
Yes, we _are_ making users happy with AA.
Questions is if we are making them secure. :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Stephen Smalley wrote:
>That would certainly help, although one might quibble with the use of
>the word "confinement" at all wrt AppArmor (it has a long-established
>technical meaning that implies information flow control, and that goes
>beyond even complete mediation - it requires global and persistent
>protection of the data based on its properties, which requires stable
>and unambiguous identifiers).
1. Yes, that's the usage that has the greatest historical claim, but
"confinement" has also been used in the security community to refer to
limiting the overt side effects a process can have rather than controlling
information flow. The term "confinement" is arguably ambiguous, but I
think there is a semi-established meaning that doesn't imply information
flow control.
2. This is a can of worms we probably don't want to open. Keep in
mind that SELinux doesn't meet definition of confinement in Lampson's
original paper, either, because it only restricts overt information flows.
SELinux doesn't prevent covert channels, even though Lampson's original
paper included them as part of the confinement problem. Yet I don't
think it would be reasonable to criticize someone for describing SELinux
as a tool for "confinement". I don't know of any practical solution
that solves the confinement problem as Lampson envisioned it. I'd
recommend making decisions on the basis of whether the mechanisms are
useful, rather than whether they solve Lampson's notion of the
"confinement" problem.
Stephen Smalley wrote:
>On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote:
>> No the "incomplete" mediation does not flow from the design. We have
>> deliberately focused on doing the necessary modifications for pathname
>> based mediation. The IPC and network mediation are a wip.
>
>The fact that you have to go back to the drawing board for them is that
>you didn't get the abstraction right in the first place.
Calling this "going back to the drawing board" board strikes me as an
unfair criticism, when the real situation is that in the future the AA
folks will need to extend their code to mediate network and IPC (not
throw all the current code away and start over from scratch, and not
replace big swaths of the current code).
I've heard four arguments against merging AA.
Argument 1. SELinux does it better than AA. (Or: SELinux dominates AA.
Or: SELinux can do everything that AA can.)
Argument 2. Object labeling (or: information flow control) is more secure
than pathname-based access control.
Argument 3. AA isn't complete until it mediates network and IPC.
Argument 4. AA doesn't have buy-in from VFS maintainers.
Let me comment on these one-by-one.
1. I think this is a bogus argument for rejecting AA. As I remember it,
the whole point of LSM was to allow merging multiple solutions and let
them compete for users on their merit, not to force the Linux maintainers
to figure out which is the best solution. Let a million flowers bloom.
2. This is argument #1 in a different guise and I find it about as weak.
Pathname-based access control has strengths and weaknesses. I think
users and Linux distributions are in a better position to evaluate those
tradeoffs than L-K. Competition is good.
3. This one I agree with. If you want to sandbox network daemons that
you're concerned might get hacked, then you really want your sandbox to
mediate everything. Right now the security provided by AA (if that's
what you are using it for) will be limited by its incomplete mediation,
since a knowledgeable motivated attacker who hacks your daemon may be
able to use network or IPC to break out of the sandbox, depending upon
the network and host configuration. Filesystem mediation alone might be
better than nothing, I suppose, if you're worried about script kiddies,
but it's certainly not a basis for strong security claims. The state of
the art in sandboxing obviously requires complete mediation, and we've
known that for a decade.
That said, I see filesystem mediation as the hard part. It's the hardest
part to implement and get right. It's the hardest part to configure
and the hardest part when it comes to designing usable policy languages.
And I suspect it's the hardest part to get merged into the Linux kernel.
And it often makes sense to start with the hard part. If AA's approach
to mediating the filesystem is acceptable, I think AA is 2/3rds of the way
to a tool that could be very useful for providing strong security claims.
There's a policy decision here: Do maintainers refuse to merge AA until
it provides complete mediation? That's a policy matter that's up to the
maintainers. I have no opinion on it. However if that is the reason
for rejecting AA it seems like it might be appropriate to come to some
decision now about whether AA's approach to filesystem mediation is
acceptable to Linux developers. I don't think it would be reasonable
to tell AA developers to go spend a few months developing network and
IPC mediation and then after they do that, to reject the whole thing on
the basis that the approach to filesystem mediation is unacceptable.
That won't encourage development of new and innovative approaches to
security, which doesn't seem like a good thing to me.
4. Way over my head. I'm not qualified to comment on this aspect.
I suspect this is the argument that ought to be getting the most serious
and thorough discussion, not the irrelevant SELinux-vs-AA faceoff.
James Morris wrote:
>The point is that the pathname model does not generalize, and that
>AppArmor's inability to provide adequate coverage of the system is a
>design issue arising from this.
I don't see it. I don't see why you call this a design issue. Isn't
this just a case where they haven't gotten around to implementing
network and IPC mediation yet? How is that a design issue arising
from a pathname-based model? For instance, one system I built (Janus)
provided complete mediation, including mediation of network and IPC,
yet it too used a pathname model for its policy file when describing
the policy for the filesystem. That seems to contradict your statement.
James Morris wrote:
>A. Pathname labeling - applying access control to pathnames to objects,
>rather than labeling the objects themselves.
>
>Think of this as, say, securing your house by putting a gate in the street
>in front of the house, regardless of how many other possible paths there
>are to the house via other streets, adjoining properties etc.
>
>Pathname labeling and mediation is simply mediating a well-known path to
>the object. In this analogy, object labeling would instead ensure that
>all of the accessible doors, windows and other entrances of the house were
>locked, so that someone trying to break in from the rear alley would
>not get in simply by bypassing the front gate and opening any door.
>
>What you do with AppArmor, instead of addressing the problem, is just
>redefine the environment along the lines of "set your house into a rock
>wall so there is only one path to it".
Harrumph. Those analogies sound good but aren't a very good guide.
Let's take a concrete example. Consider the following fragment of a
policy for Mozilla:
allow ~/.mozilla
deny ~
Ignore the syntax; the goal is to allow Mozilla to access files under
~/.mozilla but nothing else under my home directory. This is a perfectly
reasonable policy fragment to want to enforce. And enforcing it in
the obvious way using pathname-based access control is not a ridiculous
thing to do.
Yes, in theory, there could always be crazy symlinks or hardlinks
from somewhere under ~/.mozilla to elsewhere in my home directory that
would cause this policy to behave in ways different from how I desired.
In theory. But in practice this is "pretty good": good enough to be
useful in the real world. In the real world I don't have any symlinks
like that under my ~/.mozilla directory, and I'm not really worried
about unconfined processes accidentally creating a symlink under there
against my wishes. It'd be good enough for me.
Yes, pathname-based models have limitations and weaknesses, but don't
overplay them. For some purposes they are a very simple way of specifying
a desired policy and they work well enough to be useful -- a darn site
better than what we've got today. If your goal is "ease of use" and
"better than what many users are using today", it's not an unreasonable
approach. Time will tell whether it's the best solution, but it's not
obviously wrong.
And I think that's the criteria: If you want to argue that the very
idea of pathname-based access control so bogus that no approach to
pathname-based security should be merged, then you should have to argue
that it is obviously wrong and obviously not useful to users. I don't
think that burden has been met.
>B. Pathname access control as a general abstraction for OS security.
This strikes me as a strawman. Pathname-based access control is an
abstraction for mediating the *filesystem*. Who says it has to be the
way you mediate the network or IPC?
>To quote from:
>
>http://www.novell.com/linux/security/apparmor/
>
> "AppArmor gives you network application security via mandatory access
> control for programs, protecting against the exploitation of software
> flaws and compromised systems. AppArmor includes everything you need to
> provide effective containment for programs (including those that run as
> root) to thwart attempted exploits and even zero-day attacks."
>
>This is not accurate in any sense of the term containment of mandatory
>access control that I've previously encountered.
You bet. The claim you quote is totally bogus.
Bad marketers, no biscuit for you.
>The fact that it doesn't work as expected does not arise simply from
>missing features or being "different". It arises from the design of the
>system, which uses a pathname abstraction, where, even if we agree to
>ignore issue (1) above, still does not work, because only filesystem
>interactions are mediated.
Disagree.
>The "simple" policy that users can so effortlessly manipulate is simple
>because it is wrong, and deliberately so.
>
>The design of the AppArmor is based on _appearing simple_, but at the
>expense of completeness and thus correctness.
Based on my experience with Janus, my expectation is the policy isn't
going to get that much more complicated when they add mediation of
network and IPC access. I suspect it will stay almost as simple.
On Sun, 24 Jun 2007, David Wagner wrote:
> Argument 3. AA isn't complete until it mediates network and IPC.
>
> Let me comment on these one-by-one.
>
> 3. This one I agree with. If you want to sandbox network daemons that
> you're concerned might get hacked, then you really want your sandbox to
> mediate everything. Right now the security provided by AA (if that's
> what you are using it for) will be limited by its incomplete mediation,
> since a knowledgeable motivated attacker who hacks your daemon may be
> able to use network or IPC to break out of the sandbox, depending upon
> the network and host configuration. Filesystem mediation alone might be
> better than nothing, I suppose, if you're worried about script kiddies,
> but it's certainly not a basis for strong security claims. The state of
> the art in sandboxing obviously requires complete mediation, and we've
> known that for a decade.
the issue I see is that AA may not have to implement any new in-kernel
infrastructure to do this.
as recently as yesterday there have been discussions on the netfilter list
about how to implement filter rules based on the application name (see the
thread titled 'filter by application name') if this gets implemented
independantly of AA then AA could provide a policy implementation layer
over netfilter if desired (or sysadmins could just use their current
favorite tool to control the network and AA to control the filesystem)
so holding up AA becouse this isn't implemented yet seems to be counter
productive. people are working on this, and it is going to go in at some
point independantly of AA, so why tie AA to it?
IPC is a very imprecise term. it includes lots of different ways for
processes to communicate with each other. some forms of IPC are covered by
AA today (unix sockets), others aren't. but each of the different methods
is going to involve some difference in how it's controlled. if you want to
talk IPC be specific about what IPC methods you are talking bout limiting.
David Lang
Hi!
> We've been over the "AA is different" discussion in threads about a
> billion times, and at the last kernel summit. I think Lars and others
> have done a pretty good job of describing the problems they are trying
> to solve, can we please move on to discussing technical issues around
> that?
Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/
allows any user to make AA ineffective on large part of systems -- in
internal discussion. (It is not actually a _bug_, but it is certainly
unexpected).
(Does it surprise you, too? I'm pretty sure it would surprise many users).
James summarized it nicely:
# The design of the AppArmor is based on _appearing simple_, but at the
# expense of completeness and thus correctness.
If even Lars can be surprised by AAs behaviour, I do not think we can
say "AA is different". I'm afraid that AA is trap for users. It
appears simple, and mostly does what it is told, but does not do _what
user wants_.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 25 Jun 2007, Pavel Machek wrote:
> Hi!
>
>> We've been over the "AA is different" discussion in threads about a
>> billion times, and at the last kernel summit. I think Lars and others
>> have done a pretty good job of describing the problems they are trying
>> to solve, can we please move on to discussing technical issues around
>> that?
>
> Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/
> allows any user to make AA ineffective on large part of systems -- in
> internal discussion. (It is not actually a _bug_, but it is certainly
> unexpected).
>
> (Does it surprise you, too? I'm pretty sure it would surprise many users).
no, it doesn't surprise me in the least. AA is controlling access to the
thing called /etc/shadow, if you grant access to it in other ways you
bypass the restrictions.
if you follow the ln /etc/shadow /tmp/ with chmod 777 /tmp/shadow the
system is completely insecure.
this is standard stuff that normal sysadmins expect. it's only people who
have focused on the label approach who would expect it to be any
different.
> James summarized it nicely:
>
> # The design of the AppArmor is based on _appearing simple_, but at the
> # expense of completeness and thus correctness.
>
> If even Lars can be surprised by AAs behaviour, I do not think we can
> say "AA is different". I'm afraid that AA is trap for users. It
> appears simple, and mostly does what it is told, but does not do _what
> user wants_.
I thought it had been made very clear that hard links like this were a
potential way around the restrictions, which is why controlled tasks are
not allowed to do arbatrary hard links.
David Lang
On 2007-06-25T17:14:11, Pavel Machek <[email protected]> wrote:
> Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/
> allows any user to make AA ineffective on large part of systems -- in
> internal discussion. (It is not actually a _bug_, but it is certainly
> unexpected).
Pavel, no, you did not. You _did_ surprise me by misquoting me so badly,
though.
I agreed that actions by not mediated processes can interfere with
mediated processes. That is a given. So you do not give them free access
to a world writable directory.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
Chris Wright wrote:
> * Chris Mason ([email protected]) wrote:
>> I'm sure people there will have a different versions of events. The
>> one part that was discussed was if pathname based security was
>> useful, and a number of the people in the room (outside of
>> novell) said it was. Now, it could be that nobody wanted to argue
>> anymore, since most opinions had come out on one list or another by
>> then.
>>
> Indeed. The trouble is that's too high level compared with the actual
> implementation details. AA is stalled because it has failed to get
> VFS support for it's model. I don't see a nice way out unless it
> changes it's notion of policy language (globbing is the tough one)
> or gets traction to pass dentry/vfsmount all the way down. Paths are
> completely relevant for security, esp. when considering the parent dir
> and the leaf (as in forward lookup case).
To do pathname-based access control in any way, the LSM must be able to
obtain the pathname of an accessed object. The discussion should be
about the best way for an LSM to obtain the pathname of an object being
accessed.
To find the pathname of the object, LSM needs the VFS mount point data.
The VFS owns this information, so the question is the best way to convey
it from VFS to relevant LSM hooks. We are agnostic about how to get that
mount point data, but AFAICT saying that LSM can't see the mount point
data at all is equivalent to rejecting pathname based access control
entirely.
> Retroactively creating the
> full path is at the minimum ugly, and in the worst case can be insecure
> (yes AA has taken many measures to mitigate that insecurity).
>
The reverse path construction has been criticized for being both broken
and counter-intuitive. Our secure d_path patch fixes the "broken" part,
it now securely reconstructs the path. The counter-intuitive is because
forward construction of the pathname has unexpected costs, making the
retroactive construction more attractive.
> AA folks: deal with the VFS issues that your patchset have in a palatable
> way (which does not include passing NULL when it's inconvenient to
> do otherwise).
John Johansen posted a patch (written by Andreas Gruenbacher) that
introduced a nameidata2 data structure to try to solve the conditional
null passing problem, but it received no comment. A proper fix to this
problem is clearly desirable, but it also is clearly a defect in NFS and
fixing it is a lot of work; why does AA have to stay outside the kernel
until NFS is fixed, when it can easily adapt to the problem until it is
fixed properly?
> You've already missed an opportunity with Christoph's
> suggestions for changes in NFS. I know you've considered many alternative
> approaches and consistently hit dead ends. But please note, if you
> have coded yourself into a corner because of your policy language,
> that's your issue to solve, not ours.
I think it is a little more fundamental than that. If you are going to
do pathname based access control at all, you need access to sufficient
information to compute the path name. Can we have a discussion about the
best way to do that?
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor
Hi!
One more...
> 2. This is argument #1 in a different guise and I find it about as weak.
> Pathname-based access control has strengths and weaknesses. I think
> users and Linux distributions are in a better position to evaluate those
> tradeoffs than L-K. Competition is good.
It took you quite a lot of time to realize AA does not do IPC (and all
the implications of that). I do not think Linux _users_ can do
informed decision here. Novell marketing did too good job here.
Heck, even I am not sure if I understand the implications of not doing
IPC confinement. Is shared memory commonly used in a way that allows
exploiting? I know it is a problem, and you probably could kill init
from hacked apache..... but what would you do to break out of jail?
Pavel
(please cc me)
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> I've heard four arguments against merging AA.
>
> Argument 1. SELinux does it better than AA. (Or: SELinux dominates AA.
> Or: SELinux can do everything that AA can.)
>
> Argument 2. Object labeling (or: information flow control) is more secure
> than pathname-based access control.
>
> Argument 3. AA isn't complete until it mediates network and IPC.
>
> Argument 4. AA doesn't have buy-in from VFS maintainers.
...
> 1. I think this is a bogus argument for rejecting AA. As I remember it,
...
> 3. This one I agree with. If you want to sandbox network daemons that
> 4. Way over my head. I'm not qualified to comment on this aspect.
> I suspect this is the argument that ought to be getting the most serious
> and thorough discussion, not the irrelevant SELinux-vs-AA faceoff.
I believe situation is 'vfs maintainers seriously dislike AA', but if
they were given good enough reasons -- like 'selinux is broken crap
that does not really work', we probably could twist their arms or
something.
So question is not 'is AA better then SELinux' but 'is AA so much
better than SELinux that we want to overrule vfs maintainers'.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> >What you do with AppArmor, instead of addressing the problem, is just
> >redefine the environment along the lines of "set your house into a rock
> >wall so there is only one path to it".
>
> Harrumph. Those analogies sound good but aren't a very good guide.
>
> Let's take a concrete example. Consider the following fragment of a
> policy for Mozilla:
> allow ~/.mozilla
> deny ~
> Ignore the syntax; the goal is to allow Mozilla to access files under
> ~/.mozilla but nothing else under my home directory. This is a perfectly
> reasonable policy fragment to want to enforce. And enforcing it in
> the obvious way using pathname-based access control is not a ridiculous
> thing to do.
Unfortunately, mozilla needs temporary files IIRC. And when you add
allow /tmp
to your config files, you get system where your fellow users can
ln HOME/.ssh/identity /tmp/to-steal (or
ln HOME/.profile /tmp/put-evil-code-here)
and AA protection is not effective any more.
Would _you_ do this mistake?
Would our users do this mistake?
Is it right to provide them with auto-learning tools to make this
mistake really easy?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html