[apparmor] [PATCH v2] apparmor: implement profile-based query interface in apparmorfs

Kees Cook kees at ubuntu.com
Wed Mar 6 05:05:57 UTC 2013


Hi,

On Tue, Mar 05, 2013 at 06:38:35PM -0800, Tyler Hicks wrote:
> Allow userspace applications to query for allowed, denied, audit, and
> quiet permissions using a profile name and a DFA match string. Userspace
> applications that wish to enforce access controls defined in the
> system's AppArmor policy can use this interface to perform access
> control lookups.
> 
> This patch adds a new file, called .access, to the apparmorfs root
> directory. The semantics of the .access file should be hidden behind a
> libapparmor interface, but the process for doing a query looks like
> this:
> 
> open("/sys/kernel/security/apparmor/.access", O_RDWR) = 3
> write(3, "profile\0/usr/bin/app\0 system\0org"..., 98) = 98
> read(3, "allow 0x000002\ndeny 0x000000\naud"..., 1024) = 59
> close(3) = 0
> 
> The write() buffer contains the prefix specific to the current type of
> current ("profile\0" in this case), the profile name followed by a '\0',
> and the binary DFA match string. The read() buffer contains the query
> results. Here's an example of the query results:
> 
> allow 0x000002
> deny 0x000000
> audit 0x000000
> quiet 0x000000
> 
> The returned masks can be compared to the permission mask of interest.
> In the above example, the permission represented by 0x000002 would be
> allowed and the action would not be audited. The permission represented
> by 0x000001 would not be allowed and an AVC audit message would need to
> be generated.
> 
> Signed-off-by: Tyler Hicks <tyhicks at canonical.com>
> [...]
> + * Returns: number of bytes written or -errno on failure
> + */
> +static ssize_t aa_write_access(struct file *file, const char __user *ubuf,
> +			       size_t count, loff_t *ppos)
> +{
> +	char *buf;
> +	ssize_t len;
> +
> +	if (*ppos)
> +		return -ESPIPE;
> [...]
> @@ -787,6 +911,7 @@ static struct aa_fs_entry aa_fs_entry_apparmor[] = {
>  	AA_FS_FILE_FOPS(".load", 0640, &aa_fs_profile_load),
>  	AA_FS_FILE_FOPS(".replace", 0640, &aa_fs_profile_replace),
>  	AA_FS_FILE_FOPS(".remove", 0640, &aa_fs_profile_remove),
> +	AA_FS_FILE_FOPS(".access", 0666, &aa_fs_access),
>  #ifdef CONFIG_SECURITY_APPARMOR_COMPAT_24
>  	AA_FS_FILE_FOPS("profiles", 0640, &aa_fs_profiles_fops),
>  #endif

This is a mode-666 file with no check for CAP_MAC_ADMIN. Is there a reason
this is so open? Is there a chance path names could leak via this
interface? (i.e. query for a path only readable by root, etc?) On the other
hand, everything in /etc/apparmor.d/ is readable (not that it needs to be).
Could it leak dynamic profiles? The list of profiles is 0640...

-Kees

-- 
Kees Cook



More information about the AppArmor mailing list