lkml.org 
[lkml]   [2006]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH 2/11] security: AppArmor - Core headers
From
Date
On Wed, 2006-04-19 at 10:49 -0700, Tony Jones wrote:
> This patch provides the various common headerfiles used by the AppArmor module.
>
> apparmor.h contains the core data structures.
> shared.h contains definitions that are common to the userspace policy loader.
> inline.h implements various inline utility functions
>
>
> Signed-off-by: Tony Jones <tonyj@suse.de>
>
> ---
> security/apparmor/apparmor.h | 325 +++++++++++++++++++++++++++++++++++++++++
> security/apparmor/inline.h | 333 +++++++++++++++++++++++++++++++++++++++++++
> security/apparmor/shared.h | 41 +++++
> 3 files changed, 699 insertions(+)
>
> --- /dev/null
> +++ linux-2.6.17-rc1/security/apparmor/apparmor.h
> @@ -0,0 +1,325 @@
> +/*
> + * Copyright (C) 1998-2005 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 internal prototypes
> + */
> +
> +#ifndef __SUBDOMAIN_H
> +#define __SUBDOMAIN_H

this is an odd include guard for a file called apparmor.h

> +#include "shared.h"
> +
> +/* Control parameters (0 or 1), settable thru module/boot flags or
> + * via /sys/kernel/security/apparmor/control */
> +extern int apparmor_complain;
> +extern int apparmor_debug;
> +extern int apparmor_audit;
> +extern int apparmor_logsyscall;

looks like these should be in a header too

> +
> +/* PIPEFS_MAGIC */
> +#include <linux/pipe_fs_i.h>
> +/* from net/socket.c */
> +#define SOCKFS_MAGIC 0x534F434B
> +/* from inotify.c */
> +#define INOTIFYFS_MAGIC 0xBAD1DEA

> +
> +#define VALID_FSTYPE(inode) ((inode)->i_sb->s_magic != PIPEFS_MAGIC && \
> + (inode)->i_sb->s_magic != SOCKFS_MAGIC && \
> + (inode)->i_sb->s_magic != INOTIFYFS_MAGIC)

ehhhh what is this about? Isn't this highly fragile???

> +
> +/*
> + * DEBUG remains global (no per profile flag) since it is mostly used in sysctl
> + * which is not related to profile accesses.
> + */
> +
> +#define AA_DEBUG(fmt, args...) \
> + do { \
> + if (apparmor_debug) \
> + printk(KERN_DEBUG "AppArmor: " fmt, ##args); \
> + } while (0)
> +#define AA_INFO(fmt, args...) printk(KERN_INFO "AppArmor: " fmt, ##args)
> +#define AA_WARN(fmt, args...) printk(KERN_WARNING "AppArmor: " fmt, ##args)
> +#define AA_ERROR(fmt, args...) printk(KERN_ERR "AppArmor: " fmt, ##args)
> +

eh why? at least use prdebug and the like, but don't do your own

> +/* aa_audit - AppArmor auditing structure
> + * Structure is populated by access control code and passed to aa_audit which
> + * provides for a single point of logging.

why duplicate the audit infrastructure??

(and it's not possible to use LSM for auditing really; so it's not just
duplication, it's a bad idea)


> +/** aa_path_getname
> + * @data: data object previously initialized by aa_path_begin
> + *
> + * Return the next mountpoint which has the same root dentry as data->root.
> + * If no more mount points exist (or in case of error) NULL is returned
> + * (caller should call aa_path_end() and inspect return code to differentiate)
> + */
> +static inline char *aa_path_getname(struct aa_path_data *data)
> +{
> + char *name = NULL;
> + struct vfsmount *mnt;
> +
> + while (data->pos != data->head) {
> + mnt = list_entry(data->pos, struct vfsmount, mnt_list);
> +
> + /* advance to next -- so that it is done before we break */
> + data->pos = data->pos->next;
> + prefetch(data->pos->next);
> +
> + if (mnt->mnt_root == data->root) {
> + name = aa_get_name(data->dentry, mnt);
> + if (!name)
> + data->errno = -ENOMEM;
> + break;
> + }
> + }
> +
> + return name;

what's the locking rules and refcounting rules for this stuff ??



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-04-19 20:03    [W:0.394 / U:116.564 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site