Re: [PATCH 1/1] file capabilities: clear fcaps on inode change (v2)
On Mon, 2007-08-06 at 13:52 -0500, Serge E. Hallyn wrote:
From 1376764cbb54243f088cf00c39000c4f4418f461 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Mon, 6 Aug 2007 14:20:06 -0400
Subject: [PATCH 1/1] file capabilities: clear fcaps on inode change (v2)
When a file with posix capabilities is overwritten, the
file capabilities, like a setuid bit, should be removed.
This patch introduces security_inode_killpriv(). This is
currently only defined for capability, and is called when
an inode is changed to inform the security module that
it may want to clear out any privilege attached to that inode.
The capability module checks whether any file capabilities
are defined for the inode, and, if so, clears them.
Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED]
---
fs/attr.c|7 +++
fs/nfsd/vfs.c|4 ++--
fs/open.c|3 ++-
fs/splice.c |4
include/linux/fs.h |1 +
include/linux/security.h | 18 ++
mm/filemap.c |5 +
security/capability.c|1 +
security/commoncap.c | 27 +++
security/dummy.c |6 ++
security/security.c |5 +
11 files changed, 78 insertions(+), 3 deletions(-)
diff --git a/security/capability.c b/security/capability.c
index dc2b66c..e23864e 100644
--- a/security/capability.c
+++ b/security/capability.c
@@ -37,6 +37,7 @@ static struct security_operations capability_ops = {
.inode_setxattr = cap_inode_setxattr,
.inode_removexattr =cap_inode_removexattr,
+ .inode_removexattr =cap_inode_killpriv,
s/inode_removexattr/inode_killpriv/
Also, doesn't SELinux then need to define a corresponding hook function
to call the secondary module? Otherwise, it will fall back to the dummy
implementation and stacking selinux + capabilities with file caps won't
yield the right behavior.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Thu, 2007-07-19 at 15:56 +0200, Bodo Eggert wrote: > On Wed, 18 Jul 2007, Rob Landley wrote: > > On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote: > > > > I toyed with setting up a diskless system in initramfs. In the process, I > > > came across some things: > > > > > > 1) There is no way to have the kernel not mount a filesystem, > > > unless you use /init or rdinit=. > > > > Er, yes. By design. > > > > The kernel has to run an init program in order to hand off control to > > userspace. In initramfs, this is defined as /init. It looks in exactly > > one > > documented place. > > > > The older root= mechanism fell back to a half-dozen places (eventually > > trying > > things like /bin/sh if it couldn't find anything else). This is because > > there wasn't a documented standard for what should be executed, like there > > is > > with initramfs. > > Ever since I started using linux in 1997, the first program to run from an > installed system was /sbin/init. (I might think about removing the other > paths.) > > The ramfs' /init was intended for system setup, which is a separate job. > It is not intended to be the program running the system. Mixing those two > up just does not feel right. Setting root= in order to change the root > directory is much more natural. > > > > 1a) In the process of writing these patches, I found prepare_namespace not > > > to be called if /init is present. prepare_namespace will call > > > security_sb_post_mountroot after mounting the root fs. I did not yet > > > see a way to call this from /init, and grepping kinit for "security" did > > > not help, too. > > > > I don't use selinux. I'm neither a Fortune 500 company nor the NSA. > > That's no reason for keeping bugs in that part. > > > However, if you don't trust your own initramfs, where everything starts out > > running as root, you have bigger problems. > > Using that argument, you can deduce that nobody would need selinux at all. > Obviously some people disagree, and maybe some of them are no fools, > therefore we should try to DTRT for them and do the callback when it's > supposed to happen. Not wanting to get into any flamewars here about selinux, but just FYI: security_sb_post_mountroot is obsolete and can be removed without harm to selinux; it is a leftover of selinux before we moved the initial policy load to userspace. These days, initial policy load is done by /sbin/init in most distros that support selinux, although I'd prefer to do it earlier from the initramfs (the Fedora folks didn't like that idea though at the time, so /sbin/init got patched instead - but that was back in 2003, so maybe things have changed). -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
On Thu, 2007-07-19 at 15:56 +0200, Bodo Eggert wrote: On Wed, 18 Jul 2007, Rob Landley wrote: On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote: I toyed with setting up a diskless system in initramfs. In the process, I came across some things: 1) There is no way to have the kernel not mount a filesystem, unless you use /init or rdinit=. Er, yes. By design. The kernel has to run an init program in order to hand off control to userspace. In initramfs, this is defined as /init. It looks in exactly one documented place. The older root= mechanism fell back to a half-dozen places (eventually trying things like /bin/sh if it couldn't find anything else). This is because there wasn't a documented standard for what should be executed, like there is with initramfs. Ever since I started using linux in 1997, the first program to run from an installed system was /sbin/init. (I might think about removing the other paths.) The ramfs' /init was intended for system setup, which is a separate job. It is not intended to be the program running the system. Mixing those two up just does not feel right. Setting root= in order to change the root directory is much more natural. 1a) In the process of writing these patches, I found prepare_namespace not to be called if /init is present. prepare_namespace will call security_sb_post_mountroot after mounting the root fs. I did not yet see a way to call this from /init, and grepping kinit for security did not help, too. I don't use selinux. I'm neither a Fortune 500 company nor the NSA. That's no reason for keeping bugs in that part. However, if you don't trust your own initramfs, where everything starts out running as root, you have bigger problems. Using that argument, you can deduce that nobody would need selinux at all. Obviously some people disagree, and maybe some of them are no fools, therefore we should try to DTRT for them and do the callback when it's supposed to happen. Not wanting to get into any flamewars here about selinux, but just FYI: security_sb_post_mountroot is obsolete and can be removed without harm to selinux; it is a leftover of selinux before we moved the initial policy load to userspace. These days, initial policy load is done by /sbin/init in most distros that support selinux, although I'd prefer to do it earlier from the initramfs (the Fedora folks didn't like that idea though at the time, so /sbin/init got patched instead - but that was back in 2003, so maybe things have changed). -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The art of breaking userspace (was Re: [GIT] SELinux changes for 2.6.23 (updated))
On Fri, 2007-07-13 at 21:08 +0200, Michal Piotrowski wrote:
> Paul Moore pisze:
> [..]
> > On Fri, 13 Jul 2007, Michal Piotrowski wrote:
> >> My system is too secure, I can not login :)
> >>
> >> Do you have CONFIG_NETLABEL=y ?
> >>
> >> If so, please try disabling it.
> >
> > Disabling NetLabel should solve the problem.
>
> Disabling NetLabel solves the problem.
>
> > The recommended solution to this problem, as discussed on the SELinux list
> > and mentioned in the patch description, is to upgrade your SELinux policy
> > to the latest Reference Policy sources. For those with custom SELinux
> > policy, the patch description explains the changes to the SELinux policy
> > required.
>
> I'm sorry to say this, but this kind of patches should not be accepted.
>
> Patch
>
> commit 9faf65fb6ee2b4e08325ba2d69e5ccf0c46453d0
> Author: Paul Moore <[EMAIL PROTECTED]>
> Date: Fri Jun 29 11:48:16 2007 -0400
>
> SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for
> NetLabel
>
> These changes will make NetLabel behave like labeled IPsec where there is
> an
> access check for both labeled and unlabeled packets as well as providing
> the
> ability to restrict domains to receiving only labeled packets when
> NetLabel
> is in use. The changes to the policy are straight forward with the
> following necessary to receive labeled traffic (with SECINITSID_NETMSG
> defined as "netlabel_peer_t"):
>
> allow mydom_t netlabel_peer_t:{ tcp_socket udp_socket rawip_socket }
> recvfrom;
>
> The policy for unlabeled traffic would be:
>
> allow mydom_t unlabeled_t:{ tcp_socket udp_socket rawip_socket }
> recvfrom;
>
> These policy changes, as well as more general NetLabel support, are
> included
> in the SELinux Reference Policy SVN tree, r2352 or later. Users who
> enable
> NetLabel support in the kernel are strongly encouraged to upgrade their
> policy to avoid network problems.
>
> Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
> Signed-off-by: James Morris <[EMAIL PROTECTED]>
>
>
> breaks systems with recent selinux policy.
>
> (rpm -qa selinux-policy-*
> selinux-policy-devel-2.6.4-25.fc7
> selinux-policy-targeted-2.6.4-25.fc7)
>
> I will add this as a regression unless Linus says "Fsck it! We don't care
> about compatibility"
Agreed, it needs to be fixed in the netlabel code.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The art of breaking userspace (was Re: [GIT] SELinux changes for 2.6.23 (updated))
On Fri, 2007-07-13 at 21:08 +0200, Michal Piotrowski wrote:
Paul Moore pisze:
[..]
On Fri, 13 Jul 2007, Michal Piotrowski wrote:
My system is too secure, I can not login :)
Do you have CONFIG_NETLABEL=y ?
If so, please try disabling it.
Disabling NetLabel should solve the problem.
Disabling NetLabel solves the problem.
The recommended solution to this problem, as discussed on the SELinux list
and mentioned in the patch description, is to upgrade your SELinux policy
to the latest Reference Policy sources. For those with custom SELinux
policy, the patch description explains the changes to the SELinux policy
required.
I'm sorry to say this, but this kind of patches should not be accepted.
Patch
commit 9faf65fb6ee2b4e08325ba2d69e5ccf0c46453d0
Author: Paul Moore [EMAIL PROTECTED]
Date: Fri Jun 29 11:48:16 2007 -0400
SELinux: use SECINITSID_NETMSG instead of SECINITSID_UNLABELED for
NetLabel
These changes will make NetLabel behave like labeled IPsec where there is
an
access check for both labeled and unlabeled packets as well as providing
the
ability to restrict domains to receiving only labeled packets when
NetLabel
is in use. The changes to the policy are straight forward with the
following necessary to receive labeled traffic (with SECINITSID_NETMSG
defined as netlabel_peer_t):
allow mydom_t netlabel_peer_t:{ tcp_socket udp_socket rawip_socket }
recvfrom;
The policy for unlabeled traffic would be:
allow mydom_t unlabeled_t:{ tcp_socket udp_socket rawip_socket }
recvfrom;
These policy changes, as well as more general NetLabel support, are
included
in the SELinux Reference Policy SVN tree, r2352 or later. Users who
enable
NetLabel support in the kernel are strongly encouraged to upgrade their
policy to avoid network problems.
Signed-off-by: Paul Moore [EMAIL PROTECTED]
Signed-off-by: James Morris [EMAIL PROTECTED]
breaks systems with recent selinux policy.
(rpm -qa selinux-policy-*
selinux-policy-devel-2.6.4-25.fc7
selinux-policy-targeted-2.6.4-25.fc7)
I will add this as a regression unless Linus says Fsck it! We don't care
about compatibility
Agreed, it needs to be fixed in the netlabel code.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 32/44] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames
On Thu, 2007-06-28 at 20:15 +0200, Andreas Gruenbacher wrote: > On Thursday 28 June 2007 18:12, James Morris wrote: > > Are you trying to cater for the case where you're holding an open fd for a > > file which has been deleted, and thus has no pathname? > > Yes, see the AA_CHECK_FD flag in security/apparmor/main.c:aa_perm_dentry(). > We > want to distinguish between the following two cases: > > - process performs an operation on an open file descriptor, > > - process performs an operation on a pathname, and between the dentry >lookup and the LSM permission check, the file gets deleted. > > In the former case, we obviously want to continue giving the process access > to > his fd (the classical pattern: open temporary file; delete it so that it will > self-recycle, continue using the open file descriptor). > > In the latter case, The file still existed at the time of the lookup but not > anymore at the time of the permission check. The file obviously doesn't have > a filename anymore, so we cannot check permissions. If we granted access in > that case, processes could bypass their profile permissions in that race > window. We close the race by returning -ENOENT in that case, the same result > as if the file had already been deleted before the lookup. So you don't actually need/use the struct file pointer; you just need a flag indicating whether or not access was by open file descriptor or by pathname? And what does this mean for a process that has "changed hats"? Which might not be authorized to access the file anymore, even via an already opened descriptor. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] file caps: update selinux xattr hooks
sizeof XATTR_SECURITY_PREFIX - 1)) {
> + if (!strcmp(name, XATTR_NAME_CAPS)) {
> + if (!capable(CAP_SETFCAP))
> + return -EPERM;
> + } else if (!capable(CAP_SYS_ADMIN)) {
> + /* A different attribute in the security
> +namespace. Restrict to administrator. */
> + return -EPERM;
> + }
> }
>
> /* Not an attribute we recognize, so just check the
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] file caps: update selinux xattr hooks
. */ + return -EPERM; + } } /* Not an attribute we recognize, so just check the -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 32/44] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames
On Thu, 2007-06-28 at 20:15 +0200, Andreas Gruenbacher wrote: On Thursday 28 June 2007 18:12, James Morris wrote: Are you trying to cater for the case where you're holding an open fd for a file which has been deleted, and thus has no pathname? Yes, see the AA_CHECK_FD flag in security/apparmor/main.c:aa_perm_dentry(). We want to distinguish between the following two cases: - process performs an operation on an open file descriptor, - process performs an operation on a pathname, and between the dentry lookup and the LSM permission check, the file gets deleted. In the former case, we obviously want to continue giving the process access to his fd (the classical pattern: open temporary file; delete it so that it will self-recycle, continue using the open file descriptor). In the latter case, The file still existed at the time of the lookup but not anymore at the time of the permission check. The file obviously doesn't have a filename anymore, so we cannot check permissions. If we granted access in that case, processes could bypass their profile permissions in that race window. We close the race by returning -ENOENT in that case, the same result as if the file had already been deleted before the lookup. So you don't actually need/use the struct file pointer; you just need a flag indicating whether or not access was by open file descriptor or by pathname? And what does this mean for a process that has changed hats? Which might not be authorized to access the file anymore, even via an already opened descriptor. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] file caps: update selinux xattr hooks
On Thu, 2007-06-28 at 13:22 -0500, Serge E. Hallyn wrote:
> This fixes a shortcoming of the cap_setfcap patch I sent earlier,
> pointed out by Stephen Smalley.
>
> Seems to compile and boot on my little systems.
>
> thanks,
> -serge
>
> >From d729000b922a2877a48ce2b5a03a9366d8c65d04 Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Date: Thu, 28 Jun 2007 11:57:19 -0400
> Subject: [PATCH 1/1] file caps: update selinux xattr hooks
>
> SELinux does not call out to it's secondary module for setxattr
> or removexattr mediation, as the secondary module would
> incorrectly prevent writing of selinux xattrs. This means
> that when selinux and capability are both loaded, admins will
> be able to write file capabilities with CAP_SYS_ADMIN as before,
> not with CAP_SETFCAP.
>
> Update the selinux hooks to hardcode logic for the special
> consideration for file caps.
>
> I changed the flow of the removexattr hook to reduce the amount
> of indentation I was getting. It was probably written the way
> it was for a reason, and if it was, I apologize and will
> rewrite :) If it wasn't, hopefully this way is ok.
>
> Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
> ---
> security/selinux/hooks.c | 75 +
> 1 files changed, 48 insertions(+), 27 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index af42820..db0a4ed 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -2289,6 +2289,30 @@ static int selinux_inode_getattr(struct vfsmount *mnt,
> struct dentry *dentry)
> return dentry_has_perm(current, mnt, dentry, FILE__GETATTR);
> }
>
> +/* called by selinux_inode_setxattr to mediate setting
> + * of non-selinux xattrs */
> +static int selinux_inode_setotherxattr(struct dentry *dentry, char *name)
> +{
> + if (strncmp(name, XATTR_SECURITY_PREFIX,
> + sizeof XATTR_SECURITY_PREFIX - 1))
> + return dentry_has_perm(current, NULL, dentry, FILE__SETATTR);
> +
> + /* a file capability requires cap_setfcap */
> + if (!strcmp(name, XATTR_NAME_CAPS)) {
> + if (!capable(CAP_SETFCAP))
> + return -EPERM;
> + else
> + return 0;
> + }
> +
> + /* A different attribute in the security namespace.
> +Restrict to administrator. */
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + return 0;
> +}
In reworking the flow of this code, you've changed the behavior (more so
than you intended) - your checking above only applies the FILE__SETATTR
check if dealing with a non-security attribute, whereas the original
logic (below) applied that check to all non-selinux attributes. So with
your new logic, we don't get any process-to-object check for
security.cap or security., and thus lose the domain-to-type check
or the level-to-level check.
> @@ -2299,19 +2323,8 @@ static int selinux_inode_setxattr(struct dentry
> *dentry, char *name, void *value
> u32 newsid;
> int rc = 0;
>
> - if (strcmp(name, XATTR_NAME_SELINUX)) {
> - if (!strncmp(name, XATTR_SECURITY_PREFIX,
> - sizeof XATTR_SECURITY_PREFIX - 1) &&
> - !capable(CAP_SYS_ADMIN)) {
> - /* A different attribute in the security namespace.
> -Restrict to administrator. */
> - return -EPERM;
> - }
Note that if setting a security. attribute, we first check
the capability but then fall through on success to the FILE__SETATTR
check below.
> -
> - /* Not an attribute we recognize, so just check the
> -ordinary setattr permission. */
> - return dentry_has_perm(current, NULL, dentry, FILE__SETATTR);
> - }
> + if (strcmp(name, XATTR_NAME_SELINUX))
> + return selinux_inode_setotherxattr(dentry, name);
>
> sbsec = inode->i_sb->s_security;
> if (sbsec->behavior == SECURITY_FS_USE_MNTPOINT)
> @@ -2385,24 +2398,32 @@ static int selinux_inode_listxattr (struct dentry
> *dentry)
>
> static int selinux_inode_removexattr (struct dentry *dentry, char *name)
> {
> - if (strcmp(name, XATTR_NAME_SELINUX)) {
> - if (!strncmp(name, XATTR_SECURITY_PREFIX,
> - sizeof XATTR_SECURITY_PREFIX - 1) &&
> - !capable(CAP_SYS_ADMIN)) {
> - /* A different attribute in the security namespace.
> -Restrict to administrator. */
> - return -EPERM;
> - }
&
Re: [PATCH 1/1] file caps: update selinux xattr hooks
On Thu, 2007-06-28 at 13:22 -0500, Serge E. Hallyn wrote:
This fixes a shortcoming of the cap_setfcap patch I sent earlier,
pointed out by Stephen Smalley.
Seems to compile and boot on my little systems.
thanks,
-serge
From d729000b922a2877a48ce2b5a03a9366d8c65d04 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Thu, 28 Jun 2007 11:57:19 -0400
Subject: [PATCH 1/1] file caps: update selinux xattr hooks
SELinux does not call out to it's secondary module for setxattr
or removexattr mediation, as the secondary module would
incorrectly prevent writing of selinux xattrs. This means
that when selinux and capability are both loaded, admins will
be able to write file capabilities with CAP_SYS_ADMIN as before,
not with CAP_SETFCAP.
Update the selinux hooks to hardcode logic for the special
consideration for file caps.
I changed the flow of the removexattr hook to reduce the amount
of indentation I was getting. It was probably written the way
it was for a reason, and if it was, I apologize and will
rewrite :) If it wasn't, hopefully this way is ok.
Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED]
---
security/selinux/hooks.c | 75 +
1 files changed, 48 insertions(+), 27 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index af42820..db0a4ed 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2289,6 +2289,30 @@ static int selinux_inode_getattr(struct vfsmount *mnt,
struct dentry *dentry)
return dentry_has_perm(current, mnt, dentry, FILE__GETATTR);
}
+/* called by selinux_inode_setxattr to mediate setting
+ * of non-selinux xattrs */
+static int selinux_inode_setotherxattr(struct dentry *dentry, char *name)
+{
+ if (strncmp(name, XATTR_SECURITY_PREFIX,
+ sizeof XATTR_SECURITY_PREFIX - 1))
+ return dentry_has_perm(current, NULL, dentry, FILE__SETATTR);
+
+ /* a file capability requires cap_setfcap */
+ if (!strcmp(name, XATTR_NAME_CAPS)) {
+ if (!capable(CAP_SETFCAP))
+ return -EPERM;
+ else
+ return 0;
+ }
+
+ /* A different attribute in the security namespace.
+Restrict to administrator. */
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ return 0;
+}
In reworking the flow of this code, you've changed the behavior (more so
than you intended) - your checking above only applies the FILE__SETATTR
check if dealing with a non-security attribute, whereas the original
logic (below) applied that check to all non-selinux attributes. So with
your new logic, we don't get any process-to-object check for
security.cap or security.other, and thus lose the domain-to-type check
or the level-to-level check.
@@ -2299,19 +2323,8 @@ static int selinux_inode_setxattr(struct dentry
*dentry, char *name, void *value
u32 newsid;
int rc = 0;
- if (strcmp(name, XATTR_NAME_SELINUX)) {
- if (!strncmp(name, XATTR_SECURITY_PREFIX,
- sizeof XATTR_SECURITY_PREFIX - 1)
- !capable(CAP_SYS_ADMIN)) {
- /* A different attribute in the security namespace.
-Restrict to administrator. */
- return -EPERM;
- }
Note that if setting a security.non-selinux attribute, we first check
the capability but then fall through on success to the FILE__SETATTR
check below.
-
- /* Not an attribute we recognize, so just check the
-ordinary setattr permission. */
- return dentry_has_perm(current, NULL, dentry, FILE__SETATTR);
- }
+ if (strcmp(name, XATTR_NAME_SELINUX))
+ return selinux_inode_setotherxattr(dentry, name);
sbsec = inode-i_sb-s_security;
if (sbsec-behavior == SECURITY_FS_USE_MNTPOINT)
@@ -2385,24 +2398,32 @@ static int selinux_inode_listxattr (struct dentry
*dentry)
static int selinux_inode_removexattr (struct dentry *dentry, char *name)
{
- if (strcmp(name, XATTR_NAME_SELINUX)) {
- if (!strncmp(name, XATTR_SECURITY_PREFIX,
- sizeof XATTR_SECURITY_PREFIX - 1)
- !capable(CAP_SYS_ADMIN)) {
- /* A different attribute in the security namespace.
-Restrict to administrator. */
- return -EPERM;
- }
+ /* No one is allowed to remove a SELinux security label.
+You can change the label, but all data must be labeled. */
+ if (!strcmp(name, XATTR_NAME_SELINUX))
+ return -EACCES;
- /* Not an attribute we recognize, so just check the
-ordinary setattr permission. Might want a separate
-permission for removexattr. */
+ /* Not an attribute we recognize, so
Re: [PATCH try #2] security: Convert LSM into a static interface
On Mon, 2007-06-25 at 00:33 -0400, James Morris wrote: > Convert LSM into a static interface, as the ability to unload a security > module is not required by in-tree users and potentially complicates the > overall security architecture. > > Needlessly exported LSM symbols have been unexported, to help reduce API > abuse. > > Parameters for the capability and root_plug modules are now specified at > boot. > > The SECURITY_FRAMEWORK_VERSION macro has also been removed. > > Signed-off-by: James Morris <[EMAIL PROTECTED]> > --- > diff --git a/security/security.c b/security/security.c > index fc8601b..e49dae2 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -172,8 +170,5 @@ int mod_unreg_security(const char *name, struct > security_operations *ops) > return security_ops->unregister_security(name, ops); > } > > -EXPORT_SYMBOL_GPL(register_security); > -EXPORT_SYMBOL_GPL(unregister_security); > -EXPORT_SYMBOL_GPL(mod_reg_security); > -EXPORT_SYMBOL_GPL(mod_unreg_security); > +/* Export required for modular use of security.h inlines */ > EXPORT_SYMBOL(security_ops); I think you want to eliminate that last export too, by taking the security hooks that are called by modules into out-of-line wrapper functions in security.c rather than directly referencing security_ops. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH try #2] security: Convert LSM into a static interface
On Mon, 2007-06-25 at 00:33 -0400, James Morris wrote: Convert LSM into a static interface, as the ability to unload a security module is not required by in-tree users and potentially complicates the overall security architecture. Needlessly exported LSM symbols have been unexported, to help reduce API abuse. Parameters for the capability and root_plug modules are now specified at boot. The SECURITY_FRAMEWORK_VERSION macro has also been removed. Signed-off-by: James Morris [EMAIL PROTECTED] --- diff --git a/security/security.c b/security/security.c index fc8601b..e49dae2 100644 --- a/security/security.c +++ b/security/security.c @@ -172,8 +170,5 @@ int mod_unreg_security(const char *name, struct security_operations *ops) return security_ops-unregister_security(name, ops); } -EXPORT_SYMBOL_GPL(register_security); -EXPORT_SYMBOL_GPL(unregister_security); -EXPORT_SYMBOL_GPL(mod_reg_security); -EXPORT_SYMBOL_GPL(mod_unreg_security); +/* Export required for modular use of security.h inlines */ EXPORT_SYMBOL(security_ops); I think you want to eliminate that last export too, by taking the security hooks that are called by modules into out-of-line wrapper functions in security.c rather than directly referencing security_ops. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
On Wed, 2007-06-13 at 16:32 -0700, william(at)elan.net wrote: > On Thu, 14 Jun 2007, Toshiharu Harada wrote: > > > 2007/6/14, Rik van Riel <[EMAIL PROTECTED]>: > >> Toshiharu Harada wrote: > >> > 2007/6/14, Rik van Riel <[EMAIL PROTECTED]>: > >> > SELinux has a well designed robust and flexible functions. > >> > So it should be used for everywhere. I understand it. > >> > As you mentioned one can analyze the system (process) > >> > behaviors from AVC logs. But the maintenance cost is not trivial. > >> > > >> > If logging with process context is the only purpose, > >> > current TOMOYO Linux can do it with no hustle at all. > >> > >> Yes, but so does standard SELinux. > >> > >> You are making me curious: what does TOMOYO do that is > >> not done by regular SELinux? > >> > >> Logging with process name, path name and contexts is > >> already done. I must have missed some other TOMOYO > >> feature in your initial email... > > > > I see SELinux can log with process name, path name and > > contexts, but "contexts" must be defined beforehand. > > TOMOYO Linux kernel does that with pathname, so no > > label definitions needed. > > You can confirm the process (domain) transitions any time > > and access occurred are clarified per domain basis automatically. > > Security context in TOMOYO Linux is represented and stored > > as a call chain and very intuitive. > > > > TOMOYO Linux has a mode called "learning" > > in addition to "permissive" and "enforce". You can easily > > get the TOMOYO Linux policy with learning mode that > > SELinux does not have. In addition, access control mode of > > TOMOYO Linux can be managed for every difference domain. > > This sounds a like like feature differences "compared" at: > http://www.novell.com/linux/security/apparmor/selinux_comparison.html Amazing, per that table, AppArmor is better in every way than SELinux. Nothing like an unbiased and fair-minded comparison. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
On Wed, 2007-06-13 at 16:32 -0700, william(at)elan.net wrote: On Thu, 14 Jun 2007, Toshiharu Harada wrote: 2007/6/14, Rik van Riel [EMAIL PROTECTED]: Toshiharu Harada wrote: 2007/6/14, Rik van Riel [EMAIL PROTECTED]: SELinux has a well designed robust and flexible functions. So it should be used for everywhere. I understand it. As you mentioned one can analyze the system (process) behaviors from AVC logs. But the maintenance cost is not trivial. If logging with process context is the only purpose, current TOMOYO Linux can do it with no hustle at all. Yes, but so does standard SELinux. You are making me curious: what does TOMOYO do that is not done by regular SELinux? Logging with process name, path name and contexts is already done. I must have missed some other TOMOYO feature in your initial email... I see SELinux can log with process name, path name and contexts, but contexts must be defined beforehand. TOMOYO Linux kernel does that with pathname, so no label definitions needed. You can confirm the process (domain) transitions any time and access occurred are clarified per domain basis automatically. Security context in TOMOYO Linux is represented and stored as a call chain and very intuitive. TOMOYO Linux has a mode called learning in addition to permissive and enforce. You can easily get the TOMOYO Linux policy with learning mode that SELinux does not have. In addition, access control mode of TOMOYO Linux can be managed for every difference domain. This sounds a like like feature differences compared at: http://www.novell.com/linux/security/apparmor/selinux_comparison.html Amazing, per that table, AppArmor is better in every way than SELinux. Nothing like an unbiased and fair-minded comparison. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
On Wed, 2007-06-13 at 23:22 +0900, Toshiharu Harada wrote: > 2007/6/13, Stephen Smalley <[EMAIL PROTECTED]>: > > On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote: > > > Here are examples: > > > /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash > > > /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash > > > /bin/bash process invoked from /bin/bash which was invoked from sshd: > > > /usr/sbin/sshd /bin/bash /bin/bash > > > > Why can't you do this via SELinux domain transitions? That lets you do > > it by equivalence class rather than per-binary, and let's you just > > encode the security-relevant parts of the "invocation history" aka call > > chain. For example, the above could be expressed in SELinux policy > > already as: > > domain_auto_trans(getty_t, shell_exec_t, local_shell_t) > > domain_auto_trans(sshd_t, shell_exec_t, remote_shell_t) > > domain_auto_trans(remote_shell_t, shell_exec_t, remote_subshell_t) > > or whatever you like. But you don't have to keep extending it > > indefinitely when you don't need to distinguish in policy, so you might > > choose to entirely omit the last one, and just have it stay in > > remote_shell_t. > > The above SELinux policy looks similar to the one I wrote, but > that is not very true. Because in my example, path name corresponds to a file > while local_shell_t are bound to multiple. > I understand the advantages of label, but it needs to be > translated to human understandable form of path name. > So I think pathname based call chains are advantages for > at least auditing and profiling. Well, not to get into a debate, but think about whether "/usr/sbin/sshd /bin/bash" and "/sbin/mingetty /bin/bash" is more understandable to an administrator than "remote shell" vs. "local shell" - the label-based approach lets you map the low-level detail of individual programs/pathnames to abstract equivalence classes that are more understandable, not less. Further, think about the advantages of being able to encode only the security-relevant invocations, not all of them. On a different note, from a quick look, it looks like TOMOYO is AppArmor + invocation history from a user perspective. Plus a wider range of controls in your original implementation, but your LSM implementation seems to be just getting started and only deals with files. So what's the case for having a whole separate security module vs. a small extension to AppArmor? -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] TOMOYO Linux
On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote: > Hello, > > A couple of years ago, we tried to build a tool to generate > SELinux policy (*1). To do that, we had to gather the access > requests information. So we researched a profiling method and > got to the idea of having a process to store its invocation > history information (or ancestors). > > Here are examples: > /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash > /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash > /bin/bash process invoked from /bin/bash which was invoked from sshd: > /usr/sbin/sshd /bin/bash /bin/bash Why can't you do this via SELinux domain transitions? That lets you do it by equivalence class rather than per-binary, and let's you just encode the security-relevant parts of the "invocation history" aka call chain. For example, the above could be expressed in SELinux policy already as: domain_auto_trans(getty_t, shell_exec_t, local_shell_t) domain_auto_trans(sshd_t, shell_exec_t, remote_shell_t) domain_auto_trans(remote_shell_t, shell_exec_t, remote_subshell_t) or whatever you like. But you don't have to keep extending it indefinitely when you don't need to distinguish in policy, so you might choose to entirely omit the last one, and just have it stay in remote_shell_t. > It seemed to us that this clarification would be familiar to > users/administrators and could be used for various purposes. > We did implement this by making use of the Linux's traditional > fork & exec mechanisms, and built a pathname-based MAC using > this implementation. We named the result as "TOMOYO Linux" > and made it open source at SourceForge.jp (*2). > > TOMOYO Linux kernel keeps track of process invocation and > distinguishes every different process invocation history as a "domain". > TOMOYO Linux can accumulate the accesses requests for each domain. > > TOMOYO Linux has a utility called "ccstree". It prints the invocation > history for each process in addition to the output of "pstree" command: > > [EMAIL PROTECTED] ~]# ccstree > init (1) /sbin/init >+- udevd (388) /sbin/udevd >... >+- automount (1970) /etc/rc.d/init.d/autofs /usr/sbin/automount >+- acpid (1993) /etc/rc.d/init.d/acpid /bin/bash /usr/sbin/acpid >+- cupsd (2008) /etc/rc.d/init.d/cups /bin/bash /usr/sbin/cupsd >+- sshd (2026) /usr/sbin/sshd >+- sshd (2269) /usr/sbin/sshd > +- bash (2271) /usr/sbin/sshd /bin/bash >+- ccstree (15125) /usr/sbin/sshd /bin/bash > /root/ccstools/ccstree > >(symbol, "" indicates a virtual base.) > > We had a presentation and a tutorial session of TOMOYO Linux > version 1.4 at the ELC2007 (*3). Version 1.4.1 is the latest and > has a rich set of MAC functions for files, networking, and > capabilities and so on. For historical reasons, it is not using > LSM or auditd. We decided to share this idea with the Linux community > and totally rewrote the code. The result was TOMOYO Linux 2.0, > which is now using LSM and auditd. To make discussion smooth, > we cut off MAC functions other than for files. > > We are posting this message because we believe that this process > invocation history idea might be a useful addition to Linux. > Please take some time to see what this small piece of software can do > with your own eyes. Your feedback will be greatly appreciated. > > If some of you are interested in TOMOYO Linux as a method for > access control, please be advised to try full-featured version 1.4.1 (*4). > It is quite easy to install and maintain TOMOYO Linux, but it should > not be considered as a replacement of SELinux. > > All right, that's almost everything. Please visit the following > URL for the code and documents: >http://tomoyo.sourceforge.jp/wiki-e/ > If you want to see the code first, then: > > http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/security/tomoyo/?v=linux-2.6.21.3-tomoyo-2.0 > > We will have a TOMOYO Linux BOF session at the OLS2007 (*5). > Please come along and let's talk. > > Thank you. > > Toshiharu Harada (project manager) > Tetsuo Handa (main architect, version 1 author) > Kentaro Takeda (version 2.0 author) > NTT DATA CORPORATION > http://www.nttdata.co.jp/en/index.html > > *1) http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf > *2) http://tomoyo.sourceforge.jp/ > *3) http://www.celinux.org/elc2007/ > http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations > *4) http://tomoyo.sourceforge.jp/en/1.4.1/ > *5) http://www.linuxsymposium.org/2007/ > > > - > To unsubscribe from this list: send the line "unsubscribe > linux-security-module&q
Re: [RFC] TOMOYO Linux
On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote: Hello, A couple of years ago, we tried to build a tool to generate SELinux policy (*1). To do that, we had to gather the access requests information. So we researched a profiling method and got to the idea of having a process to store its invocation history information (or ancestors). Here are examples: /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash process invoked from /bin/bash which was invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash Why can't you do this via SELinux domain transitions? That lets you do it by equivalence class rather than per-binary, and let's you just encode the security-relevant parts of the invocation history aka call chain. For example, the above could be expressed in SELinux policy already as: domain_auto_trans(getty_t, shell_exec_t, local_shell_t) domain_auto_trans(sshd_t, shell_exec_t, remote_shell_t) domain_auto_trans(remote_shell_t, shell_exec_t, remote_subshell_t) or whatever you like. But you don't have to keep extending it indefinitely when you don't need to distinguish in policy, so you might choose to entirely omit the last one, and just have it stay in remote_shell_t. It seemed to us that this clarification would be familiar to users/administrators and could be used for various purposes. We did implement this by making use of the Linux's traditional fork exec mechanisms, and built a pathname-based MAC using this implementation. We named the result as TOMOYO Linux and made it open source at SourceForge.jp (*2). TOMOYO Linux kernel keeps track of process invocation and distinguishes every different process invocation history as a domain. TOMOYO Linux can accumulate the accesses requests for each domain. TOMOYO Linux has a utility called ccstree. It prints the invocation history for each process in addition to the output of pstree command: [EMAIL PROTECTED] ~]# ccstree init (1) kernel /sbin/init +- udevd (388) kernel /sbin/udevd ... +- automount (1970) kernel /etc/rc.d/init.d/autofs /usr/sbin/automount +- acpid (1993) kernel /etc/rc.d/init.d/acpid /bin/bash /usr/sbin/acpid +- cupsd (2008) kernel /etc/rc.d/init.d/cups /bin/bash /usr/sbin/cupsd +- sshd (2026) kernel /usr/sbin/sshd +- sshd (2269) kernel /usr/sbin/sshd +- bash (2271) kernel /usr/sbin/sshd /bin/bash +- ccstree (15125) kernel /usr/sbin/sshd /bin/bash /root/ccstools/ccstree (symbol, kernel indicates a virtual base.) We had a presentation and a tutorial session of TOMOYO Linux version 1.4 at the ELC2007 (*3). Version 1.4.1 is the latest and has a rich set of MAC functions for files, networking, and capabilities and so on. For historical reasons, it is not using LSM or auditd. We decided to share this idea with the Linux community and totally rewrote the code. The result was TOMOYO Linux 2.0, which is now using LSM and auditd. To make discussion smooth, we cut off MAC functions other than for files. We are posting this message because we believe that this process invocation history idea might be a useful addition to Linux. Please take some time to see what this small piece of software can do with your own eyes. Your feedback will be greatly appreciated. If some of you are interested in TOMOYO Linux as a method for access control, please be advised to try full-featured version 1.4.1 (*4). It is quite easy to install and maintain TOMOYO Linux, but it should not be considered as a replacement of SELinux. All right, that's almost everything. Please visit the following URL for the code and documents: http://tomoyo.sourceforge.jp/wiki-e/ If you want to see the code first, then: http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/security/tomoyo/?v=linux-2.6.21.3-tomoyo-2.0 We will have a TOMOYO Linux BOF session at the OLS2007 (*5). Please come along and let's talk. Thank you. Toshiharu Harada (project manager) Tetsuo Handa (main architect, version 1 author) Kentaro Takeda (version 2.0 author) NTT DATA CORPORATION http://www.nttdata.co.jp/en/index.html *1) http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf *2) http://tomoyo.sourceforge.jp/ *3) http://www.celinux.org/elc2007/ http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations *4) http://tomoyo.sourceforge.jp/en/1.4.1/ *5) http://www.linuxsymposium.org/2007/ - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org
Re: [RFC] TOMOYO Linux
On Wed, 2007-06-13 at 23:22 +0900, Toshiharu Harada wrote: 2007/6/13, Stephen Smalley [EMAIL PROTECTED]: On Wed, 2007-06-13 at 17:13 +0900, Toshiharu Harada wrote: Here are examples: /bin/bash process invoked from mingetty: /sbin/mingetty /bin/bash /bin/bash process invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash process invoked from /bin/bash which was invoked from sshd: /usr/sbin/sshd /bin/bash /bin/bash Why can't you do this via SELinux domain transitions? That lets you do it by equivalence class rather than per-binary, and let's you just encode the security-relevant parts of the invocation history aka call chain. For example, the above could be expressed in SELinux policy already as: domain_auto_trans(getty_t, shell_exec_t, local_shell_t) domain_auto_trans(sshd_t, shell_exec_t, remote_shell_t) domain_auto_trans(remote_shell_t, shell_exec_t, remote_subshell_t) or whatever you like. But you don't have to keep extending it indefinitely when you don't need to distinguish in policy, so you might choose to entirely omit the last one, and just have it stay in remote_shell_t. The above SELinux policy looks similar to the one I wrote, but that is not very true. Because in my example, path name corresponds to a file while local_shell_t are bound to multiple. I understand the advantages of label, but it needs to be translated to human understandable form of path name. So I think pathname based call chains are advantages for at least auditing and profiling. Well, not to get into a debate, but think about whether /usr/sbin/sshd /bin/bash and /sbin/mingetty /bin/bash is more understandable to an administrator than remote shell vs. local shell - the label-based approach lets you map the low-level detail of individual programs/pathnames to abstract equivalence classes that are more understandable, not less. Further, think about the advantages of being able to encode only the security-relevant invocations, not all of them. On a different note, from a quick look, it looks like TOMOYO is AppArmor + invocation history from a user perspective. Plus a wider range of controls in your original implementation, but your LSM implementation seems to be just getting started and only deals with files. So what's the case for having a whole separate security module vs. a small extension to AppArmor? -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Mon, 2007-06-11 at 17:55 +0200, Andreas Gruenbacher wrote: > On Monday 11 June 2007 16:33, Stephen Smalley wrote: > > On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote: > > > On Wednesday 06 June 2007 15:09, Stephen Smalley wrote: > > > > On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote: > > > > > On Monday 04 June 2007 15:12, Pavel Machek wrote: > > > > > > How will kernel work with very long paths? I'd suspect some > > > > > > problems, if path is 1MB long and I attempt to print it in /proc > > > > > > somewhere. > > > > > > > > > > Pathnames are only used for informational purposes in the kernel, > > > > > except in AppArmor of course. > > > > > > > > I don't mean this as a flame, but isn't the above statement the very > > > > crux of this discussion? > > > > > > I think the question at the core of it all is, shall a pathname based > > > security mechanism be allowed. I was under the impression that this > > > question had already been answered affirmatively. If the answer here was > > > no, then we could stop the entire discussion right there. > > > > There is a difference between using the pathname at the kernel/userland > > interface as part of configuring a security mechanism and using it as > > the basis for the runtime checking itself. > > Yes, there is a difference. When I say pathname based security mechanism, I > literally mean a pathname based security mechanism, meaning the pathnames > determine the outcome o the decision. This includes designs that are based on > different abstractions internally, but the bahavior observable from > user-space must be the same (or else, it's a different model). > > Unfortunately, translating pathnames to labels destroys this fundamental > abstraction. We explained why this is so in the following postings: > > http://lkml.org/lkml/2007/6/9/94 > http://lkml.org/lkml/2007/6/10/141 I don't really see the specific reasons explained in the first posting; the second one has a list of problems, but I'd question their validity: - New files: Adding the last component name as a further input to the logic for determining the label of a new file would address many of the concerns here. - Renaming: Do you honestly believe that renaming a file or directory tree should automatically change its protection without explicit action by the user/admin? I don't, naturally, and Linux DAC certainly doesn't work that way. I view the change-protections-on-rename behavior of AA as a flaw, not something to be emulated. - New Policies: So there may be more work to be done up front in the label-based approach when developing policies. Isn't that where you want to front load the work? Versus doing it at runtime? Do you expect users to be rewriting their policies constantly on their production systems? - 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? But possibly the larger question here is whether your abstraction is fundamentally broken/leaky. Even with your "native" implementation in AA, you concede that there are cases where it breaks down, right? e.g. as the path returned by d_path may in fact differ from the path that was looked up, as the tree can change between time-of-lookup and time-of-path-generation? > [cut here for lack of time right now -- will take another look later] I'm hoping you'll ultimately respond to the questions I have raised (a couple times now) about why this fundamentally differs from audit and/or inotify, which take pathnames as part of configuring the mechanism but do not generate them and match them on each access. > > > > Without the vfsmounts propagated down you won't know the pathnames. > > > Whether or not a different problem can be solved without the vfsmounts is > > > not really relevant. > > > > Well, that presumes that your mechanism has to generate full pathnames > > on each access check. But even if so, you could be doing your checking > > in the higher level code then where you have a vfsmount available. > > The LSM hooks are pretty high-level, meant for being able to plug in > different > access checks. That'
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Mon, 2007-06-11 at 14:02 -0500, Serge E. Hallyn wrote: > Quoting Andreas Gruenbacher ([EMAIL PROTECTED]): > > On Monday 11 June 2007 16:33, Stephen Smalley wrote: > > > On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote: > > > > On Wednesday 06 June 2007 15:09, Stephen Smalley wrote: > > > > > On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote: > > > > > > On Monday 04 June 2007 15:12, Pavel Machek wrote: > > > > > > > How will kernel work with very long paths? I'd suspect some > > > > > > > problems, if path is 1MB long and I attempt to print it in /proc > > > > > > > somewhere. > > > > > > > > > > > > Pathnames are only used for informational purposes in the kernel, > > > > > > except in AppArmor of course. > > > > > > > > > > I don't mean this as a flame, but isn't the above statement the very > > > > > crux of this discussion? > > > > > > > > I think the question at the core of it all is, shall a pathname based > > > > security mechanism be allowed. I was under the impression that this > > > > question had already been answered affirmatively. If the answer here was > > That was the decision at ksummit last year, yes. > > > > > no, then we could stop the entire discussion right there. > > > > > > There is a difference between using the pathname at the kernel/userland > > > interface as part of configuring a security mechanism and using it as > > > the basis for the runtime checking itself. > > > > Yes, there is a difference. When I say pathname based security mechanism, I > > literally mean a pathname based security mechanism, meaning the pathnames > > determine the outcome o the decision. This includes designs that are based > > on > > different abstractions internally, but the bahavior observable from > > user-space must be the same (or else, it's a different model). > > > > Unfortunately, translating pathnames to labels destroys this fundamental > > abstraction. We explained why this is so in the following postings: > > > > http://lkml.org/lkml/2007/6/9/94 > > http://lkml.org/lkml/2007/6/10/141 > > > > > Further, there is a difference between generating and matching full > > > pathnames on each access vs. caching information in the parent dentry and > > > making decisions based on that cached information and the last > > > component-name. > > > > Wait, you are mixing two issues here: access checks on existing files, and > > the > > creation of new files. For AppArmor as it stands today the two are the > > same, > > but when looking at emulating AppArmor using labels, they are not. Let's > > look > > at things one at a time. > > > > Generating and matching full pathnames on each access takes time, no > > question > > about that. (In fact we are not checking on each access but only when > > pathnames are involved, such as on open. Filehandle based operations do not > > require access checks, but that's not a very important difference at this > > level of discussion.) That's a quantitative statement though, not a > > qualitative one: retrieving xattrs and checking labels also takes time; > > additional checks are never for free. We find that doing the pathname > > checks > > is easily fast enough. You may disagree, but then you don't have to use > > AppArmor, and we are not standing in your way. > > > > As far as new files are concerned, basing decisions on the parent dentry > > and > > component name requires that you know where in the filesystem hierarchy > > this > > dentry is located: with bind mounts, the same dentry shows up in multiple > > locations in a process's namespace, corresponding to different pathnames. > > In > > other words, to make the right decision, the dentry alone is not enough; it > > takes a pair. So there we are again. > > > > >From the point on where you have a pair of objects, you > > >can > > do two things: you can compute the full pathname and base your decision on > > that, or you can do some caching to hopefully cut some of that work short > > frequently enough to set off the additional cost. The difference between > > the > > two approaches is quantitative -- if there is a difference in results, then > > that's obviously a bug. I believe that caching could speed up things > > measurably, but up to this point
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Mon, 2007-06-11 at 14:02 -0500, Serge E. Hallyn wrote: Quoting Andreas Gruenbacher ([EMAIL PROTECTED]): On Monday 11 June 2007 16:33, Stephen Smalley wrote: On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote: On Wednesday 06 June 2007 15:09, Stephen Smalley wrote: On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote: On Monday 04 June 2007 15:12, Pavel Machek wrote: How will kernel work with very long paths? I'd suspect some problems, if path is 1MB long and I attempt to print it in /proc somewhere. Pathnames are only used for informational purposes in the kernel, except in AppArmor of course. I don't mean this as a flame, but isn't the above statement the very crux of this discussion? I think the question at the core of it all is, shall a pathname based security mechanism be allowed. I was under the impression that this question had already been answered affirmatively. If the answer here was That was the decision at ksummit last year, yes. no, then we could stop the entire discussion right there. There is a difference between using the pathname at the kernel/userland interface as part of configuring a security mechanism and using it as the basis for the runtime checking itself. Yes, there is a difference. When I say pathname based security mechanism, I literally mean a pathname based security mechanism, meaning the pathnames determine the outcome o the decision. This includes designs that are based on different abstractions internally, but the bahavior observable from user-space must be the same (or else, it's a different model). Unfortunately, translating pathnames to labels destroys this fundamental abstraction. We explained why this is so in the following postings: http://lkml.org/lkml/2007/6/9/94 http://lkml.org/lkml/2007/6/10/141 Further, there is a difference between generating and matching full pathnames on each access vs. caching information in the parent dentry and making decisions based on that cached information and the last component-name. Wait, you are mixing two issues here: access checks on existing files, and the creation of new files. For AppArmor as it stands today the two are the same, but when looking at emulating AppArmor using labels, they are not. Let's look at things one at a time. Generating and matching full pathnames on each access takes time, no question about that. (In fact we are not checking on each access but only when pathnames are involved, such as on open. Filehandle based operations do not require access checks, but that's not a very important difference at this level of discussion.) That's a quantitative statement though, not a qualitative one: retrieving xattrs and checking labels also takes time; additional checks are never for free. We find that doing the pathname checks is easily fast enough. You may disagree, but then you don't have to use AppArmor, and we are not standing in your way. As far as new files are concerned, basing decisions on the parent dentry and component name requires that you know where in the filesystem hierarchy this dentry is located: with bind mounts, the same dentry shows up in multiple locations in a process's namespace, corresponding to different pathnames. In other words, to make the right decision, the dentry alone is not enough; it takes a dentry, vfsmount pair. So there we are again. From the point on where you have a dentry, vfsmount pair of objects, you can do two things: you can compute the full pathname and base your decision on that, or you can do some caching to hopefully cut some of that work short frequently enough to set off the additional cost. The difference between the two approaches is quantitative -- if there is a difference in results, then that's obviously a bug. I believe that caching could speed up things measurably, but up to this point, neither I nor anybody else had the time to look into it, and so we are not doing it -- not yet, any perhaps never at all. It may be counter to your intuition, but doing those checks is not a big issue. My approach in DTE, which used pathnames to assign TE labels in the kernel, was to use a 'shadow tree' to the vfsmnt+dentry tree, filled out at policy load time to the depth of the deepest policy rule. For the behavior I was after, bind mounts were handled by storing pointers from the new mount to the original, but the behavior AA wants would be different. Namespace clones are easily handled this way by copying the cached pointers to the shadow tree. And it was pretty fast. When I talked about this with Tony last year, the biggest shortcoming to use this for AA was the wildcards. For instance, if there is a rule for /var/log/HOSTS/*/messages
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Mon, 2007-06-11 at 17:55 +0200, Andreas Gruenbacher wrote: On Monday 11 June 2007 16:33, Stephen Smalley wrote: On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote: On Wednesday 06 June 2007 15:09, Stephen Smalley wrote: On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote: On Monday 04 June 2007 15:12, Pavel Machek wrote: How will kernel work with very long paths? I'd suspect some problems, if path is 1MB long and I attempt to print it in /proc somewhere. Pathnames are only used for informational purposes in the kernel, except in AppArmor of course. I don't mean this as a flame, but isn't the above statement the very crux of this discussion? I think the question at the core of it all is, shall a pathname based security mechanism be allowed. I was under the impression that this question had already been answered affirmatively. If the answer here was no, then we could stop the entire discussion right there. There is a difference between using the pathname at the kernel/userland interface as part of configuring a security mechanism and using it as the basis for the runtime checking itself. Yes, there is a difference. When I say pathname based security mechanism, I literally mean a pathname based security mechanism, meaning the pathnames determine the outcome o the decision. This includes designs that are based on different abstractions internally, but the bahavior observable from user-space must be the same (or else, it's a different model). Unfortunately, translating pathnames to labels destroys this fundamental abstraction. We explained why this is so in the following postings: http://lkml.org/lkml/2007/6/9/94 http://lkml.org/lkml/2007/6/10/141 I don't really see the specific reasons explained in the first posting; the second one has a list of problems, but I'd question their validity: - New files: Adding the last component name as a further input to the logic for determining the label of a new file would address many of the concerns here. - Renaming: Do you honestly believe that renaming a file or directory tree should automatically change its protection without explicit action by the user/admin? I don't, naturally, and Linux DAC certainly doesn't work that way. I view the change-protections-on-rename behavior of AA as a flaw, not something to be emulated. - New Policies: So there may be more work to be done up front in the label-based approach when developing policies. Isn't that where you want to front load the work? Versus doing it at runtime? Do you expect users to be rewriting their policies constantly on their production systems? - 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? But possibly the larger question here is whether your abstraction is fundamentally broken/leaky. Even with your native implementation in AA, you concede that there are cases where it breaks down, right? e.g. as the path returned by d_path may in fact differ from the path that was looked up, as the tree can change between time-of-lookup and time-of-path-generation? [cut here for lack of time right now -- will take another look later] I'm hoping you'll ultimately respond to the questions I have raised (a couple times now) about why this fundamentally differs from audit and/or inotify, which take pathnames as part of configuring the mechanism but do not generate them and match them on each access. Without the vfsmounts propagated down you won't know the pathnames. Whether or not a different problem can be solved without the vfsmounts is not really relevant. Well, that presumes that your mechanism has to generate full pathnames on each access check. But even if so, you could be doing your checking in the higher level code then where you have a vfsmount available. The LSM hooks are pretty high-level, meant for being able to plug in different access checks. That's the right level of abstraction. We just need the vfsmounts passed down as well. That's what the bulk of common code patches are there for. Well, if you succeed in that, does that mean that the read-only bind mount folks should go back to that approach? Just looking for a little bit of consistency among different efforts... -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote: > On Wednesday 06 June 2007 15:09, Stephen Smalley wrote: > > On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote: > > > On Monday 04 June 2007 15:12, Pavel Machek wrote: > > > > How will kernel work with very long paths? I'd suspect some problems, > > > > if path is 1MB long and I attempt to print it in /proc > > > > somewhere. > > > > > > Pathnames are only used for informational purposes in the kernel, except > > > in AppArmor of course. > > > > I don't mean this as a flame, but isn't the above statement the very > > crux of this discussion? > > I think the question at the core of it all is, shall a pathname based > security > mechanism be allowed. I was under the impression that this question had > already been answered affirmatively. If the answer here was no, then we could > stop the entire discussion right there. There is a difference between using the pathname at the kernel/userland interface as part of configuring a security mechanism and using it as the basis for the runtime checking itself. Further, there is a difference between generating and matching full pathnames on each access vs. caching information in the parent dentry and making decisions based on that cached information and the last component-name. The only question I saw being answered was the abstract one of "can a pathname play a role in the security mechanism" not "should the kernel be regenerating a full path on each open and glob matching it against a list of file globs." > > Why should AppArmor be different from the rest of the kernel in its usage of > > pathnames (basis for decisions vs. informational reporting to userspace)? > > And if it is ok for AppArmor to generate and use pathnames as its basis of > > decisions on each open, then is it also ok for audit, inotify, and others to > > use them in the same manner? > > Audit and inotify don't make any decisions based on pathnames, or on SELinux > labels for that matter, they only report. That being said, sure those parts > of the kernel that report pathnames should report them correctly -- I guess > there is no disagreement about that. >From a userland perspective, audit and inotify allow you to specify watches on pathnames, and those watches trigger actions by the audit and inotify subsystems when those files are accessed. The kernel mechanism however is inode-based, not pathname-based; the pathname is merely looked up when the watch is added and mapped to an inode. That's my point - why should AA be different? Would you really recommend that audit or inotify call d_path() on each open and glob match the result against a list of audit or inotify watches? BTW, audit does allow filters on SELinux labels these days. > > Another question: it seems like the read-only bind mount folks gave up > > on propagating the vfsmounts down and switched to a rather different > > approach (checking near the entry points, using mount writer counters). > > So similarly, what makes AppArmor fundamentally different that it > > wouldn't take a similar approach to what they are doing vs. propagating > > the vfsmounts down? > > Without the vfsmounts propagated down you won't know the pathnames. Whether > or not a different problem can be solved without the vfsmounts is not really > relevant. Well, that presumes that your mechanism has to generate full pathnames on each access check. But even if so, you could be doing your checking in the higher level code then where you have a vfsmount available. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote: On Wednesday 06 June 2007 15:09, Stephen Smalley wrote: On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote: On Monday 04 June 2007 15:12, Pavel Machek wrote: How will kernel work with very long paths? I'd suspect some problems, if path is 1MB long and I attempt to print it in /proc somewhere. Pathnames are only used for informational purposes in the kernel, except in AppArmor of course. I don't mean this as a flame, but isn't the above statement the very crux of this discussion? I think the question at the core of it all is, shall a pathname based security mechanism be allowed. I was under the impression that this question had already been answered affirmatively. If the answer here was no, then we could stop the entire discussion right there. There is a difference between using the pathname at the kernel/userland interface as part of configuring a security mechanism and using it as the basis for the runtime checking itself. Further, there is a difference between generating and matching full pathnames on each access vs. caching information in the parent dentry and making decisions based on that cached information and the last component-name. The only question I saw being answered was the abstract one of can a pathname play a role in the security mechanism not should the kernel be regenerating a full path on each open and glob matching it against a list of file globs. Why should AppArmor be different from the rest of the kernel in its usage of pathnames (basis for decisions vs. informational reporting to userspace)? And if it is ok for AppArmor to generate and use pathnames as its basis of decisions on each open, then is it also ok for audit, inotify, and others to use them in the same manner? Audit and inotify don't make any decisions based on pathnames, or on SELinux labels for that matter, they only report. That being said, sure those parts of the kernel that report pathnames should report them correctly -- I guess there is no disagreement about that. From a userland perspective, audit and inotify allow you to specify watches on pathnames, and those watches trigger actions by the audit and inotify subsystems when those files are accessed. The kernel mechanism however is inode-based, not pathname-based; the pathname is merely looked up when the watch is added and mapped to an inode. That's my point - why should AA be different? Would you really recommend that audit or inotify call d_path() on each open and glob match the result against a list of audit or inotify watches? BTW, audit does allow filters on SELinux labels these days. Another question: it seems like the read-only bind mount folks gave up on propagating the vfsmounts down and switched to a rather different approach (checking near the entry points, using mount writer counters). So similarly, what makes AppArmor fundamentally different that it wouldn't take a similar approach to what they are doing vs. propagating the vfsmounts down? Without the vfsmounts propagated down you won't know the pathnames. Whether or not a different problem can be solved without the vfsmounts is not really relevant. Well, that presumes that your mechanism has to generate full pathnames on each access check. But even if so, you could be doing your checking in the higher level code then where you have a vfsmount available. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] very high non-preempt latency in context_struct_compute_av()
On Mon, 2007-06-04 at 13:27 +0200, Ingo Molnar wrote: > a simple ssh login triggers a ~130 msecs non-preemptible latency even > with CONFIG_PREEMPT enabled, on a fast Core2Duo CPU (!). > > the latency is caused by a _very_ long loop in the SELinux code: > > sshd-4828 0.N.. 465894us : avtab_search_node (context_struct_compute_av) > sshd-4828 0.N.. 465895us : cond_compute_av (context_struct_compute_av) > sshd-4828 0.N.. 465895us : avtab_search_node (cond_compute_av) > sshd-4828 0.N.. 465895us : avtab_search_node (context_struct_compute_av) > sshd-4828 0.N.. 465896us : cond_compute_av (context_struct_compute_av) > sshd-4828 0.N.. 465896us : avtab_search_node (cond_compute_av) > sshd-4828 0.N.. 465896us : avtab_search_node (context_struct_compute_av) > sshd-4828 0.N.. 465896us : cond_compute_av (context_struct_compute_av) > sshd-4828 0.N.. 465896us : avtab_search_node (cond_compute_av) > > it is triggered like this: > > sshd-4828 0..s. 462986us : tasklet_action (__do_softirq) > sshd-4828 0..s. 462986us : rcu_process_callbacks (tasklet_action) > sshd-4828 0..s. 462986us : __rcu_process_callbacks > (rcu_process_callbacks) > sshd-4828 0..s. 462987us : __rcu_process_callbacks > (rcu_process_callbacks) > sshd-4828 0D.s. 462987us : _local_bh_enable (__do_softirq) > sshd-4828 0DN.. 462987us : idle_cpu (irq_exit) > sshd-4828 0.N.. 462988us : avtab_search_node (context_struct_compute_av) > sshd-4828 0.N.. 462989us : cond_compute_av (context_struct_compute_av) > > and it ends like this after 130 msecs: > > sshd-4828 0.N.. 594068us : ebitmap_contains (constraint_expr_eval) > sshd-4828 0.N.. 594068us : ebitmap_get_bit (constraint_expr_eval) > sshd-4828 0.N.. 594068us : constraint_expr_eval > (context_struct_compute_av) > sshd-4828 0.N.. 594068us : ebitmap_contains (constraint_expr_eval) > sshd-4828 0.N.. 594068us : ebitmap_get_bit (constraint_expr_eval) > sshd-4828 0.N.. 594070us : sprintf (sel_write_user) > sshd-4828 0.N.. 594070us : vsnprintf (sprintf) > sshd-4828 0.N.. 594072us : number (vsnprintf) > sshd-4828 0.N.. 594072us : security_sid_to_context (sel_write_user) > sshd-4828 0.N.. 594073us : _read_lock (security_sid_to_context) > sshd-4828 0.N.. 594073us : sidtab_search (security_sid_to_context) > sshd-4828 0.N.. 594073us : context_struct_to_string > (security_sid_to_context) > sshd-4828 0.N.. 594074us : mls_compute_context_len > (context_struct_to_string) > sshd-4828 0.N.. 594075us : ebitmap_cmp (mls_compute_context_len) > sshd-4828 0.N.. 594075us : __kmalloc (context_struct_to_string) > sshd-4828 0.N.. 594076us : sprintf (context_struct_to_string) > sshd-4828 0.N.. 594077us : vsnprintf (sprintf) > > i've got the full trace saved away (200 MB ...) and can upload it, but > it's just repetitions of the above lines. > > The distribution is Fedora 7, v2.6.21 (but also happens in recent -git) > and a simple 'ssh localhost' login is enough to trigger this. It > triggers every time and this is causing audio skipping in certain apps. > It is even visible in glxgears smoothness: a small 'bump' is visible in > the otherwise smooth rotation of glxgears. Enabling CONFIG_PREEMPT does > not fix this issue as the function runs under spinlocks. (enabling > CONFIG_PREEMPT_RT in -rt fixes the issue - but that still leaves us with > the huge 130 msecs cost of that function.) Can you try the patch below to see whether it helps? In security_get_user_sids, move the transition permission checks outside of the section holding the policy rdlock, and use the AVC to perform the checks, calling cond_resched after each one. These changes should allow preemption between the individual checks and enable caching of the results. It may however increase the overall time spent in the function in some cases, particularly in the cache miss case. The long term fix will be to take much of this logic to userspace by exporting additional state via selinuxfs, and ultimately deprecating and eliminating this interface from the kernel. Signed-off-by: Stephen Smalley <[EMAIL PROTECTED]> --- security/selinux/avc.c | 10 +--- security/selinux/hooks.c |9 --- security/selinux/include/avc.h |6 +++-- security/selinux/ss/services.c | 49 + 4 files changed, 45 insertions(+), 29 deletions(-) diff --git a/security/selinux/avc.c b/security/selinux/avc.c index e4396a8..cc5fcef 100644 --- a/security/selinux/avc.c +++ b/security/selinux/avc.c @@ -832,6 +832,7 @@ int avc_ss_reset(u32 seqno) * @tsid: target security identifier * @tclass: target security class * @requested: requested permissions, inter
Re: [bug] very high non-preempt latency in context_struct_compute_av()
On Mon, 2007-06-04 at 13:27 +0200, Ingo Molnar wrote: a simple ssh login triggers a ~130 msecs non-preemptible latency even with CONFIG_PREEMPT enabled, on a fast Core2Duo CPU (!). the latency is caused by a _very_ long loop in the SELinux code: sshd-4828 0.N.. 465894us : avtab_search_node (context_struct_compute_av) sshd-4828 0.N.. 465895us : cond_compute_av (context_struct_compute_av) sshd-4828 0.N.. 465895us : avtab_search_node (cond_compute_av) sshd-4828 0.N.. 465895us : avtab_search_node (context_struct_compute_av) sshd-4828 0.N.. 465896us : cond_compute_av (context_struct_compute_av) sshd-4828 0.N.. 465896us : avtab_search_node (cond_compute_av) sshd-4828 0.N.. 465896us : avtab_search_node (context_struct_compute_av) sshd-4828 0.N.. 465896us : cond_compute_av (context_struct_compute_av) sshd-4828 0.N.. 465896us : avtab_search_node (cond_compute_av) it is triggered like this: sshd-4828 0..s. 462986us : tasklet_action (__do_softirq) sshd-4828 0..s. 462986us : rcu_process_callbacks (tasklet_action) sshd-4828 0..s. 462986us : __rcu_process_callbacks (rcu_process_callbacks) sshd-4828 0..s. 462987us : __rcu_process_callbacks (rcu_process_callbacks) sshd-4828 0D.s. 462987us : _local_bh_enable (__do_softirq) sshd-4828 0DN.. 462987us : idle_cpu (irq_exit) sshd-4828 0.N.. 462988us : avtab_search_node (context_struct_compute_av) sshd-4828 0.N.. 462989us : cond_compute_av (context_struct_compute_av) and it ends like this after 130 msecs: sshd-4828 0.N.. 594068us : ebitmap_contains (constraint_expr_eval) sshd-4828 0.N.. 594068us : ebitmap_get_bit (constraint_expr_eval) sshd-4828 0.N.. 594068us : constraint_expr_eval (context_struct_compute_av) sshd-4828 0.N.. 594068us : ebitmap_contains (constraint_expr_eval) sshd-4828 0.N.. 594068us : ebitmap_get_bit (constraint_expr_eval) sshd-4828 0.N.. 594070us : sprintf (sel_write_user) sshd-4828 0.N.. 594070us : vsnprintf (sprintf) sshd-4828 0.N.. 594072us : number (vsnprintf) sshd-4828 0.N.. 594072us : security_sid_to_context (sel_write_user) sshd-4828 0.N.. 594073us : _read_lock (security_sid_to_context) sshd-4828 0.N.. 594073us : sidtab_search (security_sid_to_context) sshd-4828 0.N.. 594073us : context_struct_to_string (security_sid_to_context) sshd-4828 0.N.. 594074us : mls_compute_context_len (context_struct_to_string) sshd-4828 0.N.. 594075us : ebitmap_cmp (mls_compute_context_len) sshd-4828 0.N.. 594075us : __kmalloc (context_struct_to_string) sshd-4828 0.N.. 594076us : sprintf (context_struct_to_string) sshd-4828 0.N.. 594077us : vsnprintf (sprintf) i've got the full trace saved away (200 MB ...) and can upload it, but it's just repetitions of the above lines. The distribution is Fedora 7, v2.6.21 (but also happens in recent -git) and a simple 'ssh localhost' login is enough to trigger this. It triggers every time and this is causing audio skipping in certain apps. It is even visible in glxgears smoothness: a small 'bump' is visible in the otherwise smooth rotation of glxgears. Enabling CONFIG_PREEMPT does not fix this issue as the function runs under spinlocks. (enabling CONFIG_PREEMPT_RT in -rt fixes the issue - but that still leaves us with the huge 130 msecs cost of that function.) Can you try the patch below to see whether it helps? In security_get_user_sids, move the transition permission checks outside of the section holding the policy rdlock, and use the AVC to perform the checks, calling cond_resched after each one. These changes should allow preemption between the individual checks and enable caching of the results. It may however increase the overall time spent in the function in some cases, particularly in the cache miss case. The long term fix will be to take much of this logic to userspace by exporting additional state via selinuxfs, and ultimately deprecating and eliminating this interface from the kernel. Signed-off-by: Stephen Smalley [EMAIL PROTECTED] --- security/selinux/avc.c | 10 +--- security/selinux/hooks.c |9 --- security/selinux/include/avc.h |6 +++-- security/selinux/ss/services.c | 49 + 4 files changed, 45 insertions(+), 29 deletions(-) diff --git a/security/selinux/avc.c b/security/selinux/avc.c index e4396a8..cc5fcef 100644 --- a/security/selinux/avc.c +++ b/security/selinux/avc.c @@ -832,6 +832,7 @@ int avc_ss_reset(u32 seqno) * @tsid: target security identifier * @tclass: target security class * @requested: requested permissions, interpreted based on @tclass + * @flags: AVC_STRICT or 0 * @avd: access vector decisions * * Check the AVC to determine whether the @requested permissions are granted @@ -846,8 +847,9 @@ int avc_ss_reset(u32 seqno) * should be released for the auditing
Re: [PATCH] Protection for exploiting null dereference using mmap
On Wed, 2007-06-06 at 02:30 -0400, Eric Paris wrote:
> On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
> > On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
> > > This should be an unsigned long.
> > >
> > > I wonder if the default should be for this value to be zero (i.e.
> > > preserve
> > > existing behavior). It could break binaries, albeit potentially insecure
> >
> > Agreed - DOSemu type apps and lrmi need to map at zero for vm86
>
> And so it shall be!
>
> Signed-off-by: Eric Paris <[EMAIL PROTECTED]>
With the fix already noted by James,
Acked-by: Stephen Smalley <[EMAIL PROTECTED]>
Note that you need to also submit a patch for policy to reserve that
class to avoid future collisions.
>
> ---
>
> Documentation/sysctl/kernel.txt | 14 ++
> include/linux/security.h | 17 -
> kernel/sysctl.c |8
> mm/mmap.c|4 ++--
> mm/mremap.c | 13 +++--
> mm/nommu.c |2 +-
> security/dummy.c |6 +-
> security/security.c |2 ++
> security/selinux/hooks.c | 12
> security/selinux/include/av_perm_to_string.h |1 +
> security/selinux/include/av_permissions.h|1 +
> security/selinux/include/class_to_string.h |1 +
> security/selinux/include/flask.h |1 +
> 13 files changed, 67 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index 111fd28..be3991c 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -29,6 +29,7 @@ show up in /proc/sys/kernel:
> - java-interpreter[ binfmt_java, obsolete ]
> - kstack_depth_to_print [ X86 only ]
> - l2cr[ PPC only ]
> +- mmap_min_addr
> - modprobe==> Documentation/kmod.txt
> - msgmax
> - msgmnb
> @@ -178,6 +179,19 @@ kernel stack.
>
> ==
>
> +mmap_min_addr
> +
> +This file indicates the amount of address space which a user process will be
> +restricted from mmaping. Since kernel null dereference bugs could
> +accidentally operate based on the information in the first couple of pages of
> +memory userspace processes should not be allowed to write to them. By
> default
> +this value is set to 0 and no protections will be enforced by the security
> +module. Setting this value to something like 64k will allow the vast
> majority
> +of applications to work correctly and provide defense in depth against future
> +potential kernel bugs.
> +
> +==
> +
> osrelease, ostype & version:
>
> # cat osrelease
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 9eb9e0f..c11dc8a 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -71,6 +71,7 @@ struct xfrm_user_sec_ctx;
> extern int cap_netlink_send(struct sock *sk, struct sk_buff *skb);
> extern int cap_netlink_recv(struct sk_buff *skb, int cap);
>
> +extern unsigned long mmap_min_addr;
> /*
> * Values used in the task_security_ops calls
> */
> @@ -1241,8 +1242,9 @@ struct security_operations {
> int (*file_ioctl) (struct file * file, unsigned int cmd,
> unsigned long arg);
> int (*file_mmap) (struct file * file,
> - unsigned long reqprot,
> - unsigned long prot, unsigned long flags);
> + unsigned long reqprot, unsigned long prot,
> + unsigned long flags, unsigned long addr,
> + unsigned long addr_only);
> int (*file_mprotect) (struct vm_area_struct * vma,
> unsigned long reqprot,
> unsigned long prot);
> @@ -1814,9 +1816,12 @@ static inline int security_file_ioctl (struct file
> *file, unsigned int cmd,
>
> static inline int security_file_mmap (struct file *file, unsigned long
> reqprot,
> unsigned long prot,
> - unsigned long flags)
> + unsigned long flags,
> + unsigned long addr,
> + unsigned long addr_only)
> {
> - r
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote: > On Monday 04 June 2007 15:12, Pavel Machek wrote: > > How will kernel work with very long paths? I'd suspect some problems, > > if path is 1MB long and I attempt to print it in /proc > > somewhere. > > Pathnames are only used for informational purposes in the kernel, except in > AppArmor of course. I don't mean this as a flame, but isn't the above statement the very crux of this discussion? Why should AppArmor be different from the rest of the kernel in its usage of pathnames (basis for decisions vs. informational reporting to userspace)? And if it is ok for AppArmor to generate and use pathnames as its basis of decisions on each open, then is it also ok for audit, inotify, and others to use them in the same manner? If the audit developers or inotify developers had come with patches that used d_path or equivalent in the same manner as AppArmor, don't you think they would have gotten the same resistance? And if you are truly trying to create a mechanism (in AppArmor) that you can ultimately apply widely to the system (going beyond AppArmor's original limited focus on a small set of network-facing daemons), aren't you concerned about the implications of having to generate a pathname on each open just to decide what to do? Is this really the "path" you want to take ;)? Another question: it seems like the read-only bind mount folks gave up on propagating the vfsmounts down and switched to a rather different approach (checking near the entry points, using mount writer counters). So similarly, what makes AppArmor fundamentally different that it wouldn't take a similar approach to what they are doing vs. propagating the vfsmounts down? Or do you think they made the wrong choice? If so, why? Just trying to understand your position better... -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Protection for exploiting null dereference using mmap
On Tue, 2007-06-05 at 17:28 -0400, Eric Paris wrote: > On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote: > > On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote: > > > This should be an unsigned long. > > > > > > I wonder if the default should be for this value to be zero (i.e. > > > preserve > > > existing behavior). It could break binaries, albeit potentially insecure > > > > Agreed - DOSemu type apps and lrmi need to map at zero for vm86 > > While I understand, there are a few users who will have problems with > this default are we really better to not provide this defense in depth > for the majority of users and let those with problems turn it off rather > than provide no defense by default? I could even provide a different > default for SELinux and non-SELinux if anyone saw value in that? But if > others think that off default is best I'll send another patch shortly > with the unsigned long fix and the default set to 0. My hope is then > that distros will figure out to turn this on. I'd be ok with having a different default for SELinux vs. non-SELinux, i.e. no restrictions by default under dummy/capability, but restrict it by default to 64k if selinux is enabled. Then we can use policy to grant it as needed to the specific programs. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Protection for exploiting null dereference using mmap
On Wed, 2007-06-06 at 19:01 +1000, Russell Coker wrote:
> On Wednesday 06 June 2007 06:34, Eric Paris <[EMAIL PROTECTED]> wrote:
> > This patch uses a new SELinux security class "memprotect." Policy
> > already contains a number of allow rules like a_t self:process *
> > (unconfined_t being one of them) which mean that putting this check in
> > the process class (its best current fit) would make it useless as all
>
> I think it would be best to use the process class and change the "*" rules to
> ~{ memprotect }.
Eric originally used process class, but I asked him to put it into a
separate class. I think that current refpolicy actually doesn't have
any allow a_t self:process *; rules because we already had to refactor
all such rules when we introduced execmem and friends, but that doesn't
mean that there are not legacy policies with such rules, and I'd prefer
to isolate especially security-sensitive permissions in distinct classes
(and we are running out of room in process class).
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Protection for exploiting null dereference using mmap
On Tue, 2007-06-05 at 15:53 -0700, Chris Wright wrote: > * Eric Paris ([EMAIL PROTECTED]) wrote: > > One result of using the dummy hook for non-selinux kernels means that I > > can't leave the generic module stacking code in the SELinux check. If > > the secondary ops are called they will always deny the operation just > > like in non-selinux systems even if SELinux policy would have allowed > > the action. This patch may be the first step to removing the arbitrary > > LSM module stacking code from SELinux. I think history has shown the > > arbitrary module stacking is not a good idea and eventually I want to > > pull out all the secondary calls which aren't used by the capability > > module, so I view this as just the first step along those lines. > > Or replace them all with direct library calls to the capability code. The only tricky part there is retaining the support for falling back on capabilities upon runtime disable of selinux by /sbin/init. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Protection for exploiting null dereference using mmap
On Tue, 2007-06-05 at 15:53 -0700, Chris Wright wrote: * Eric Paris ([EMAIL PROTECTED]) wrote: One result of using the dummy hook for non-selinux kernels means that I can't leave the generic module stacking code in the SELinux check. If the secondary ops are called they will always deny the operation just like in non-selinux systems even if SELinux policy would have allowed the action. This patch may be the first step to removing the arbitrary LSM module stacking code from SELinux. I think history has shown the arbitrary module stacking is not a good idea and eventually I want to pull out all the secondary calls which aren't used by the capability module, so I view this as just the first step along those lines. Or replace them all with direct library calls to the capability code. The only tricky part there is retaining the support for falling back on capabilities upon runtime disable of selinux by /sbin/init. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Protection for exploiting null dereference using mmap
On Wed, 2007-06-06 at 19:01 +1000, Russell Coker wrote:
On Wednesday 06 June 2007 06:34, Eric Paris [EMAIL PROTECTED] wrote:
This patch uses a new SELinux security class memprotect. Policy
already contains a number of allow rules like a_t self:process *
(unconfined_t being one of them) which mean that putting this check in
the process class (its best current fit) would make it useless as all
I think it would be best to use the process class and change the * rules to
~{ memprotect }.
Eric originally used process class, but I asked him to put it into a
separate class. I think that current refpolicy actually doesn't have
any allow a_t self:process *; rules because we already had to refactor
all such rules when we introduced execmem and friends, but that doesn't
mean that there are not legacy policies with such rules, and I'd prefer
to isolate especially security-sensitive permissions in distinct classes
(and we are running out of room in process class).
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Protection for exploiting null dereference using mmap
On Tue, 2007-06-05 at 17:28 -0400, Eric Paris wrote: On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote: On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote: This should be an unsigned long. I wonder if the default should be for this value to be zero (i.e. preserve existing behavior). It could break binaries, albeit potentially insecure Agreed - DOSemu type apps and lrmi need to map at zero for vm86 While I understand, there are a few users who will have problems with this default are we really better to not provide this defense in depth for the majority of users and let those with problems turn it off rather than provide no defense by default? I could even provide a different default for SELinux and non-SELinux if anyone saw value in that? But if others think that off default is best I'll send another patch shortly with the unsigned long fix and the default set to 0. My hope is then that distros will figure out to turn this on. I'd be ok with having a different default for SELinux vs. non-SELinux, i.e. no restrictions by default under dummy/capability, but restrict it by default to 64k if selinux is enabled. Then we can use policy to grant it as needed to the specific programs. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote: On Monday 04 June 2007 15:12, Pavel Machek wrote: How will kernel work with very long paths? I'd suspect some problems, if path is 1MB long and I attempt to print it in /proc somewhere. Pathnames are only used for informational purposes in the kernel, except in AppArmor of course. I don't mean this as a flame, but isn't the above statement the very crux of this discussion? Why should AppArmor be different from the rest of the kernel in its usage of pathnames (basis for decisions vs. informational reporting to userspace)? And if it is ok for AppArmor to generate and use pathnames as its basis of decisions on each open, then is it also ok for audit, inotify, and others to use them in the same manner? If the audit developers or inotify developers had come with patches that used d_path or equivalent in the same manner as AppArmor, don't you think they would have gotten the same resistance? And if you are truly trying to create a mechanism (in AppArmor) that you can ultimately apply widely to the system (going beyond AppArmor's original limited focus on a small set of network-facing daemons), aren't you concerned about the implications of having to generate a pathname on each open just to decide what to do? Is this really the path you want to take ;)? Another question: it seems like the read-only bind mount folks gave up on propagating the vfsmounts down and switched to a rather different approach (checking near the entry points, using mount writer counters). So similarly, what makes AppArmor fundamentally different that it wouldn't take a similar approach to what they are doing vs. propagating the vfsmounts down? Or do you think they made the wrong choice? If so, why? Just trying to understand your position better... -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Protection for exploiting null dereference using mmap
On Wed, 2007-06-06 at 02:30 -0400, Eric Paris wrote:
On Tue, 2007-06-05 at 17:16 -0400, Alan Cox wrote:
On Tue, Jun 05, 2007 at 05:00:51PM -0400, James Morris wrote:
This should be an unsigned long.
I wonder if the default should be for this value to be zero (i.e.
preserve
existing behavior). It could break binaries, albeit potentially insecure
Agreed - DOSemu type apps and lrmi need to map at zero for vm86
And so it shall be!
Signed-off-by: Eric Paris [EMAIL PROTECTED]
With the fix already noted by James,
Acked-by: Stephen Smalley [EMAIL PROTECTED]
Note that you need to also submit a patch for policy to reserve that
class to avoid future collisions.
---
Documentation/sysctl/kernel.txt | 14 ++
include/linux/security.h | 17 -
kernel/sysctl.c |8
mm/mmap.c|4 ++--
mm/mremap.c | 13 +++--
mm/nommu.c |2 +-
security/dummy.c |6 +-
security/security.c |2 ++
security/selinux/hooks.c | 12
security/selinux/include/av_perm_to_string.h |1 +
security/selinux/include/av_permissions.h|1 +
security/selinux/include/class_to_string.h |1 +
security/selinux/include/flask.h |1 +
13 files changed, 67 insertions(+), 15 deletions(-)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 111fd28..be3991c 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -29,6 +29,7 @@ show up in /proc/sys/kernel:
- java-interpreter[ binfmt_java, obsolete ]
- kstack_depth_to_print [ X86 only ]
- l2cr[ PPC only ]
+- mmap_min_addr
- modprobe== Documentation/kmod.txt
- msgmax
- msgmnb
@@ -178,6 +179,19 @@ kernel stack.
==
+mmap_min_addr
+
+This file indicates the amount of address space which a user process will be
+restricted from mmaping. Since kernel null dereference bugs could
+accidentally operate based on the information in the first couple of pages of
+memory userspace processes should not be allowed to write to them. By
default
+this value is set to 0 and no protections will be enforced by the security
+module. Setting this value to something like 64k will allow the vast
majority
+of applications to work correctly and provide defense in depth against future
+potential kernel bugs.
+
+==
+
osrelease, ostype version:
# cat osrelease
diff --git a/include/linux/security.h b/include/linux/security.h
index 9eb9e0f..c11dc8a 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -71,6 +71,7 @@ struct xfrm_user_sec_ctx;
extern int cap_netlink_send(struct sock *sk, struct sk_buff *skb);
extern int cap_netlink_recv(struct sk_buff *skb, int cap);
+extern unsigned long mmap_min_addr;
/*
* Values used in the task_security_ops calls
*/
@@ -1241,8 +1242,9 @@ struct security_operations {
int (*file_ioctl) (struct file * file, unsigned int cmd,
unsigned long arg);
int (*file_mmap) (struct file * file,
- unsigned long reqprot,
- unsigned long prot, unsigned long flags);
+ unsigned long reqprot, unsigned long prot,
+ unsigned long flags, unsigned long addr,
+ unsigned long addr_only);
int (*file_mprotect) (struct vm_area_struct * vma,
unsigned long reqprot,
unsigned long prot);
@@ -1814,9 +1816,12 @@ static inline int security_file_ioctl (struct file
*file, unsigned int cmd,
static inline int security_file_mmap (struct file *file, unsigned long
reqprot,
unsigned long prot,
- unsigned long flags)
+ unsigned long flags,
+ unsigned long addr,
+ unsigned long addr_only)
{
- return security_ops-file_mmap (file, reqprot, prot, flags);
+ return security_ops-file_mmap (file, reqprot, prot, flags, addr,
+ addr_only);
}
static inline int security_file_mprotect (struct vm_area_struct *vma,
@@ -2489,7 +2494,9 @@ static inline int security_file_ioctl (struct file
*file, unsigned int cmd,
static inline int security_file_mmap (struct file *file, unsigned long
reqprot
Re: [bug] very high non-preempt latency in context_struct_compute_av()
On Mon, 2007-06-04 at 17:11 -0400, Paul Moore wrote:
> On Monday, June 4 2007 7:27:45 am Ingo Molnar wrote:
> > a simple ssh login triggers a ~130 msecs non-preemptible latency even
> > with CONFIG_PREEMPT enabled, on a fast Core2Duo CPU (!).
> >
> > the latency is caused by a _very_ long loop in the SELinux code:
> >
> > sshd-4828 0.N.. 465894us : avtab_search_node
> > (context_struct_compute_av) sshd-4828 0.N.. 465895us : cond_compute_av
> > (context_struct_compute_av) sshd-4828 0.N.. 465895us : avtab_search_node
> > (cond_compute_av) sshd-4828 0.N.. 465895us : avtab_search_node
> > (context_struct_compute_av) sshd-4828 0.N.. 465896us : cond_compute_av
> > (context_struct_compute_av) sshd-4828 0.N.. 465896us : avtab_search_node
> > (cond_compute_av) sshd-4828 0.N.. 465896us : avtab_search_node
> > (context_struct_compute_av) sshd-4828 0.N.. 465896us : cond_compute_av
> > (context_struct_compute_av) sshd-4828 0.N.. 465896us : avtab_search_node
> > (cond_compute_av)
> >
> > it is triggered like this:
> >
> > sshd-4828 0..s. 462986us : tasklet_action (__do_softirq)
> > sshd-4828 0..s. 462986us : rcu_process_callbacks (tasklet_action)
> > sshd-4828 0..s. 462986us : __rcu_process_callbacks
> > (rcu_process_callbacks) sshd-4828 0..s. 462987us : __rcu_process_callbacks
> > (rcu_process_callbacks) sshd-4828 0D.s. 462987us : _local_bh_enable
> > (__do_softirq)
> > sshd-4828 0DN.. 462987us : idle_cpu (irq_exit)
> > sshd-4828 0.N.. 462988us : avtab_search_node
> > (context_struct_compute_av) sshd-4828 0.N.. 462989us : cond_compute_av
> > (context_struct_compute_av)
> >
> > {snip}
> >
> > The distribution is Fedora 7, v2.6.21 (but also happens in recent -git)
> > and a simple 'ssh localhost' login is enough to trigger this. It
> > triggers every time and this is causing audio skipping in certain apps.
> > It is even visible in glxgears smoothness: a small 'bump' is visible in
> > the otherwise smooth rotation of glxgears. Enabling CONFIG_PREEMPT does
> > not fix this issue as the function runs under spinlocks. (enabling
> > CONFIG_PREEMPT_RT in -rt fixes the issue - but that still leaves us with
> > the huge 130 msecs cost of that function.)
>
> I'm not an expert on the SELinux security server guts like the other people
> on
> the To/CC line of this thread, but here are my two cents on the issue above.
>
> >From what I can tell the nasty loop that is taking so long is the actual
> access vector lookup which determines if the subject has access to the object
> (i.e. can user/application X access resource Y on the system). While it may
> be possible to optimize this code I wonder if a quicker/easier solution would
> be to refactor the lock. At present SELinux uses a read/write spinlock to
> protect the policy stored in the kernel with macros to take and release the
> lock, POLICY_{RD,WR}LOCK and POLICY_{RD,WR}UNLOCK. From personal
> observations as well as a quick check of the code, it appears that most of
> the time we only want to read lock the policy and not write lock the policy -
> a spinlock, even a read/write spinlock, seems a bit expensive here.
>
> If we were to convert from a read/write spinlock to a RCU locking mechanism
> would this solve the preemption problem (I'm not a lock expert either)? If
> so, can anyone think of any reasons why converting the policy lock to RCU is
> a bad idea (James, Stephen, the other James)?
rcu_read_lock disables preemption in mainline (see rcupdate.h).
Conversion to RCU is also complicated by conditional policy support
(changing of policy boolean states via selinuxfs). However, there were
experimental patches to do that a while ago by KaiGai Kohei.
I think that there are several factors here:
- targeted policy yields an explosion in the possible transitions at
login time since users are effectively unconfined there. There would be
far fewer computations under strict policy.
- sel_write_user -> security_get_user_sids does a lot of work while
holding the policy rdlock, including all of those compute_av calls
inside of its own loops. This is the function that is computing
reachable contexts for the user (role set) based on policy from the
initial login context at login time. I think this function can be
refactored to drop and retake locks appropriately and to introduce
cond_resched calls.
- compute_av has potentially long loops internally if the policy makes
significant use of attributes; this was the tradeoff in memory vs.
performance introduced by the patches to reduce the avtab memory use
introduced in 2.6.14. In the common case, you don't see it due to the
AVC caching the results of compute_av but security_g
Re: [bug] very high non-preempt latency in context_struct_compute_av()
On Mon, 2007-06-04 at 17:11 -0400, Paul Moore wrote:
On Monday, June 4 2007 7:27:45 am Ingo Molnar wrote:
a simple ssh login triggers a ~130 msecs non-preemptible latency even
with CONFIG_PREEMPT enabled, on a fast Core2Duo CPU (!).
the latency is caused by a _very_ long loop in the SELinux code:
sshd-4828 0.N.. 465894us : avtab_search_node
(context_struct_compute_av) sshd-4828 0.N.. 465895us : cond_compute_av
(context_struct_compute_av) sshd-4828 0.N.. 465895us : avtab_search_node
(cond_compute_av) sshd-4828 0.N.. 465895us : avtab_search_node
(context_struct_compute_av) sshd-4828 0.N.. 465896us : cond_compute_av
(context_struct_compute_av) sshd-4828 0.N.. 465896us : avtab_search_node
(cond_compute_av) sshd-4828 0.N.. 465896us : avtab_search_node
(context_struct_compute_av) sshd-4828 0.N.. 465896us : cond_compute_av
(context_struct_compute_av) sshd-4828 0.N.. 465896us : avtab_search_node
(cond_compute_av)
it is triggered like this:
sshd-4828 0..s. 462986us : tasklet_action (__do_softirq)
sshd-4828 0..s. 462986us : rcu_process_callbacks (tasklet_action)
sshd-4828 0..s. 462986us : __rcu_process_callbacks
(rcu_process_callbacks) sshd-4828 0..s. 462987us : __rcu_process_callbacks
(rcu_process_callbacks) sshd-4828 0D.s. 462987us : _local_bh_enable
(__do_softirq)
sshd-4828 0DN.. 462987us : idle_cpu (irq_exit)
sshd-4828 0.N.. 462988us : avtab_search_node
(context_struct_compute_av) sshd-4828 0.N.. 462989us : cond_compute_av
(context_struct_compute_av)
{snip}
The distribution is Fedora 7, v2.6.21 (but also happens in recent -git)
and a simple 'ssh localhost' login is enough to trigger this. It
triggers every time and this is causing audio skipping in certain apps.
It is even visible in glxgears smoothness: a small 'bump' is visible in
the otherwise smooth rotation of glxgears. Enabling CONFIG_PREEMPT does
not fix this issue as the function runs under spinlocks. (enabling
CONFIG_PREEMPT_RT in -rt fixes the issue - but that still leaves us with
the huge 130 msecs cost of that function.)
I'm not an expert on the SELinux security server guts like the other people
on
the To/CC line of this thread, but here are my two cents on the issue above.
From what I can tell the nasty loop that is taking so long is the actual
access vector lookup which determines if the subject has access to the object
(i.e. can user/application X access resource Y on the system). While it may
be possible to optimize this code I wonder if a quicker/easier solution would
be to refactor the lock. At present SELinux uses a read/write spinlock to
protect the policy stored in the kernel with macros to take and release the
lock, POLICY_{RD,WR}LOCK and POLICY_{RD,WR}UNLOCK. From personal
observations as well as a quick check of the code, it appears that most of
the time we only want to read lock the policy and not write lock the policy -
a spinlock, even a read/write spinlock, seems a bit expensive here.
If we were to convert from a read/write spinlock to a RCU locking mechanism
would this solve the preemption problem (I'm not a lock expert either)? If
so, can anyone think of any reasons why converting the policy lock to RCU is
a bad idea (James, Stephen, the other James)?
rcu_read_lock disables preemption in mainline (see rcupdate.h).
Conversion to RCU is also complicated by conditional policy support
(changing of policy boolean states via selinuxfs). However, there were
experimental patches to do that a while ago by KaiGai Kohei.
I think that there are several factors here:
- targeted policy yields an explosion in the possible transitions at
login time since users are effectively unconfined there. There would be
far fewer computations under strict policy.
- sel_write_user - security_get_user_sids does a lot of work while
holding the policy rdlock, including all of those compute_av calls
inside of its own loops. This is the function that is computing
reachable contexts for the user (role set) based on policy from the
initial login context at login time. I think this function can be
refactored to drop and retake locks appropriately and to introduce
cond_resched calls.
- compute_av has potentially long loops internally if the policy makes
significant use of attributes; this was the tradeoff in memory vs.
performance introduced by the patches to reduce the avtab memory use
introduced in 2.6.14. In the common case, you don't see it due to the
AVC caching the results of compute_av but security_get_user_sids doesn't
go through the AVC. That's harder to fix.
I think we can try refactoring security_get_user_sids and see how much
that helps.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
file capabilities and security_task_wait failure Re: 2.6.22 -mm merge plans
On Mon, 2007-04-30 at 16:20 -0700, Andrew Morton wrote: > implement-file-posix-capabilities.patch > file-capabilities-accomodate-future-64-bit-caps.patch > return-eperm-not-echild-on-security_task_wait-failure.patch > > I think we're still waiting for the security guys to work out what to do with > this work. return-eperm-not-echild-on-security_task_wait-failure.patch should be merged - it is effectively a bug fix. On the file capabilities support, have any of the filesystem folks (cc'd) looked at the code yet? -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
file capabilities and security_task_wait failure Re: 2.6.22 -mm merge plans
On Mon, 2007-04-30 at 16:20 -0700, Andrew Morton wrote: implement-file-posix-capabilities.patch file-capabilities-accomodate-future-64-bit-caps.patch return-eperm-not-echild-on-security_task_wait-failure.patch I think we're still waiting for the security guys to work out what to do with this work. return-eperm-not-echild-on-security_task_wait-failure.patch should be merged - it is effectively a bug fix. On the file capabilities support, have any of the filesystem folks (cc'd) looked at the code yet? -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 2007-04-19 at 20:54 +, David Wagner wrote:
> Stephen Smalley wrote:
> >Integrity protection requires information flow control; you can't
> >protect a high integrity process from being corrupted by a low integrity
> >process if you don't control the flow of information. Plenty of attacks
> >take the form of a untrusted process injecting data that will ultimately
> >be used by a more trusted process with a surprising side effect.
>
> I don't agree with this blanket statement. In a number of cases
> of practical interest, useful integrity protection can be achieved
> without full information flow control. Suppose you have a malicious
> ("low integrity") process A, and a target ("high integrity") process B.
> We want to prevent A from attacking B. One way to do that is to ensure
> that A has no overt channel it can use to attack process B, by severely
> restricting A's ability to cause side effects on the rest of the world.
> This is often sufficient to contain the damage that A can do.
If you could do that, I'd call that information flow control - I wasn't
saying you had to eliminate covert channels. As you said, we don't deal
with those even in SELinux. The point is that AA can't even do that,
not only because it has incomplete controls but because it bases its
decisions on unreliable identifiers (paths) that doesn't let it provide
global and persistent protection of the data.
> Of course, if the intended functionality of the system requires A to
> communicate data to B, and if you don't trust B's ability to handle
> that data carefully enough, and if A is malicious, then you've got a
> serious problem.
>
> But in a number of cases (enough cases to be useful), you can provide
> a useful level of security without needing information flow control and
> without needing global, persistent labels.
Without a reliable way of identifying the data in a system view, you
can't say anything at all about the data flows. The labels provide you
with a way of doing that. The paths are ambiguous, highly mutable, and
often meaningless (particularly for runtime files, temporary files, etc)
from a security pov.
Simple example: malicious symlink attacks.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 2007-04-19 at 20:08 +, David Wagner wrote: > Stephen Smalley wrote: > >Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM > >Vol 16 No 10) means information flow control, which you have agreed > >AppArmor does not and cannot provide. > > Right, that's how I understand it, too. > > However, I think some more caveats are in order. In all honesty, > I don't think SELinux solves Lampson's problem, either. > > It is useful to distinguish between "bit-confinement" (confining the > flow of information, a la Lampson) vs "authority-confinement" (confining > the flow of privileges and the ability of the untrusted app to cause > side effects on the rest of the system). > > No Linux system provides bit-confinement, if the confined app is > malicious. AppArmor does not provide bit-confinement. Neither does > SELinux. SELinux can stop some kinds of accidental leakage of secrets, > but it cannot prevent deliberate attempts to leak the secrets that are > known to malicious apps. The reason is that, in every system under > consideration, it is easy for a malicious app to leak any secrets it might > have to the outside world by using covert channels (e.g., wall-banging). > In practical terms, Lampson's bit-confinement problem is just not > solvable. Oh well, so it goes. > > A good jail needs to provide authority-confinement, but thankfully, > it doesn't need to provide bit-confinement. I don't know enough about > AppArmor to know whether it is able to do a good job of providing > authority-confinement. If it cannot, then it deserves criticism on > those grounds. > > Often the pragmatic solution to the covert channel problem is to ensure > that untrusted apps are never given access to critical secrets in the > first place. They can't leak something they don't know. This solves the > confidentiality problem by avoiding any attempt to tackle the unsolvable > bit-confinement problem. > > Note that the problem of building a good jail is a little different from > the information flow control problem. First, I think there is practical value in providing confidentiality control on the overt channels, even if covert channels remain. We have to start somewhere. Second, information flow is not just a confidentiality issue - see my other email. It is quite important as well for integrity, and integrity corruption in order to assume control over a privileged subject or trick it into abusing its power can be done solely via a data channel - it doesn't require explicit flow of authority. Lastly, if you want to judge AA as a jail mechanism, I think you'll find it fails there too. So where does that leave it? An easy-to-use yet inadequate solution for MAC or jail. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote: > David Safford wrote: > > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: > > > >> On Mon, 16 Apr 2007, John Johansen wrote: > >> > >>> Label-based security (exemplified by SELinux, and its predecessors in > >>> MLS systems) attaches security policy to the data. As the data flows > >>> through the system, the label sticks to the data, and so security > >>> policy with respect to this data stays intact. This is a good approach > >>> for ensuring secrecy, the kind of problem that intelligence agencies have. > >>> > >> Labels are also a good approach for ensuring integrity, which is one of > >> the most fundamental aspects of the security model implemented by SELinux. > >> > >> > >> Some may infer otherwise from your document. > >> > > In fact, I am not sure how you can provide integrity support without > > labels. AppArmor confines a process, but does not effectively confine > > its output files, precisely because the output files are not labeled. > > Other processes are free to access the unlabeled, potentially malicious > > output files without restriction. > > > That depends on what you mean by "integrity." It is true that AppArmor > does not directly manage information flow. AppArmor assumes that if you > granted write permission to /etc/resolv.conf, that you meant to do that. > Whether any other process is permitted to access /etc/resolv.conf is > determined by those other process's respective profiles. Integrity protection requires information flow control; you can't protect a high integrity process from being corrupted by a low integrity process if you don't control the flow of information. Plenty of attacks take the form of a untrusted process injecting data that will ultimately be used by a more trusted process with a surprising side effect. And you can't do information flow control if you can't provide global and persistent protection of the data, which requires labeling it and preserving that label for its lifetime. > What AppArmor provides is a way for administrators to confine software > that they have to run but do not trust. The use of pathnames means that > the administrator can understand the exact meaning of the security > policy, without having to do a complete labeling of the file system. The > flip side of not managing information flow is that each profile is > independent of every other profile. They aren't truly independent; the composition may lead to surprising results where each individual program is "confined" exactly as you specified, but in combination, one is able to corrupt the higher integrity subject by actions taken by the lower integrity subject. Particularly in the fun area of publically writable directories, where pathnames are largely useless as an indicator. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 20:05 +0200, Andi Kleen wrote: > Karl MacMillan <[EMAIL PROTECTED]> writes: > > > No - the real fix is to change the applications or to run under a policy > > that confines all applications. Most of the problems with resolv.conf, > > mtab, etc. stem from admin processes (e.g., editors or shell scripts) > > all running under the same unconfined domain. > > > > In some cases applications need modification as only the application has > > enough information to determine the correct label. Usually this means > > preserving labels from input files or separating the output into > > distinct directories so type transitions or label inheritance will work. > > > > restorecond is just a hack not a requirement or a sign that something is > > wrong with the model. That is why it is a userspace application and not > > integrated into the kernel mechanism. > > You nicely show one of the major disadvantages of the label model vs the path > model here: it requires modification of a lot of applications. It is true that many applications that already deal with mode bits need to become aware of labels, just as with ACLs, and that this makes it a bit harder and slower to roll out something that is label-based. But the right solution is rarely quick and easy, and a lot of work has already happened to integrate such support into userland. To look at it in a slightly different way, the AA emphasis on not modifying applications could be viewed as a limitation. Ultimately, users have security goals that go beyond just what the OS can directly enforce and at least some applications (notably things like X, D-BUS, PostgreSQL, etc) need to likewise support strong domain separation and controlled information flow through their own internal objects and operations. SELinux provides APIs and infrastructure for such applications, and has already done quite a bit of work in that space (D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have no interest in going there (and would have to recant its emphasis on no application mods to do so). If you actually want to truly confine a desktop application, you can't limit yourself to the kernel. And the label model provides a unifying abstraction for dealing with all of these various objects, whereas the path/"natural abstraction" model has no unifying abstraction at all. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 2007-04-19 at 16:35 +, David Wagner wrote: > James Morris wrote: > >On Wed, 18 Apr 2007, Crispin Cowan wrote: > >> How is it that you think a buffer overflow in httpd could allow an > >> attacker to break out of an AppArmor profile? > > > >Because you can change the behavior of the application and then bypass > >policy entirely by utilizing any mechanism other than direct filesystem > >access: IPC, shared memory, Unix domain sockets, local IP networking, > >remote networking etc. > > Any halfway decent jail will let you control access to all of those > things, thereby preventing an 0wned httpd from breaking out of the jail. > (For instance, Janus did. So does Systrace.) > > Are you saying AppArmor does not allow that kind of control? Specifics > would be useful. Just look at their code and their own description of AppArmor. It does not provide that level of control, and by your own metric, it is thus not a halfway decent jail. Which begs the question - if that is the kind of approach you want, why not use a real jail/containers mechanism for it? > >Also worth noting here is that you have to consider any limited > >environment as enforcing security policy, and thus its configuration > >becomes an additional component of security policy. > > I don't understand what you are saying. Yes, the AppArmor policy > file is part of policy. Is that what you mean? I think he means the dependencies on which AppArmor relies, not just its policy, e.g. since it is name-based, it presumes the filesystem namespace has been set up by a trusted agent and is correct. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 2007-04-18 at 13:15 -0700, David Lang wrote: > On Wed, 18 Apr 2007, James Morris wrote: > > > On Tue, 17 Apr 2007, Alan Cox wrote: > > > >> I'm not sure if AppArmor can be made good security for the general case, > >> but it is a model that works in the limited http environment > >> (eg .htaccess) and is something people can play with and hack on and may > >> be possible to configure to be very secure. > > > > Perhaps -- until your httpd is compromised via a buffer overflow or > > simply misbehaves due to a software or configuration flaw, then the > > assumptions being made about its use of pathnames and their security > > properties are out the window. > > since AA defines a whitelist of files that httpd is allowed to access, a > comprimised one may be able to mess up it's files, but it's still not going > to > be able to touch other files on the system. > > > Without security labeling of the objects being accessed, you can't protect > > against software flaws, which has been a pretty fundamental and widely > > understood requirement in general computing for at least a decade. > > this is not true. you don't need to label all object and chunks of memory, > you > just need to have a way to list (and enforce) the objects and memory that the > program is allowed to use. labeling them is one way of doing this, but not > the > only way. You need a way of providing global and persistent security guarantees for the data, and per-program profiles based on pathname don't get you there. There is no system view in AA, just a bunch of disconnected profiles. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 2007-04-18 at 12:41 -0700, Crispin Cowan wrote: > James Morris wrote: > > On Tue, 17 Apr 2007, Alan Cox wrote: > > > >> I'm not sure if AppArmor can be made good security for the general case, > >> but it is a model that works in the limited http environment > >> (eg .htaccess) and is something people can play with and hack on and may > >> be possible to configure to be very secure. > >> > > Perhaps -- until your httpd is compromised via a buffer overflow or > > simply misbehaves due to a software or configuration flaw, then the > > assumptions being made about its use of pathnames and their security > > properties are out the window. > > > How is it that you think a buffer overflow in httpd could allow an > attacker to break out of an AppArmor profile? This is exactly what > AppArmor was designed to do, and without specifics, this is just FUD. > > > Without security labeling of the objects being accessed, you can't protect > > against software flaws, which has been a pretty fundamental and widely > > understood requirement in general computing for at least a decade. > > > Please explain why labels are necessary for effective confinement. Many > systems besides AppArmor have used non-label schemes for effective > confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS, > AS400, to name just a few. This claim seems bogus. Labels may be your > method of choice for confinement, but they are far from the only way. Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM Vol 16 No 10) means information flow control, which you have agreed AppArmor does not and cannot provide. Yes? As to the (genuine) capability-based systems, have a look at the DTOS General System Security and Assurability Assessment Report for why we have concerns with their approach. But that has nothing to do with AppArmor. Look, if you would just refrain from making misleading statements about SELinux (not only in this FAQ but throughout your documents and talks), especially when we've previously refuted those same statements (as in the first AppArmor submission and its discussion), and honestly acknowledged the limitations of your approach without trying to spin them as strengths, I think that there would be nothing to discuss here. We could just agree to disagree, and you could just focus on addressing the issues raised by the vfs folks about how to get your changes into an acceptable form. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 2007-04-18 at 12:41 -0700, Crispin Cowan wrote: James Morris wrote: On Tue, 17 Apr 2007, Alan Cox wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? This is exactly what AppArmor was designed to do, and without specifics, this is just FUD. Without security labeling of the objects being accessed, you can't protect against software flaws, which has been a pretty fundamental and widely understood requirement in general computing for at least a decade. Please explain why labels are necessary for effective confinement. Many systems besides AppArmor have used non-label schemes for effective confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS, AS400, to name just a few. This claim seems bogus. Labels may be your method of choice for confinement, but they are far from the only way. Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM Vol 16 No 10) means information flow control, which you have agreed AppArmor does not and cannot provide. Yes? As to the (genuine) capability-based systems, have a look at the DTOS General System Security and Assurability Assessment Report for why we have concerns with their approach. But that has nothing to do with AppArmor. Look, if you would just refrain from making misleading statements about SELinux (not only in this FAQ but throughout your documents and talks), especially when we've previously refuted those same statements (as in the first AppArmor submission and its discussion), and honestly acknowledged the limitations of your approach without trying to spin them as strengths, I think that there would be nothing to discuss here. We could just agree to disagree, and you could just focus on addressing the issues raised by the vfs folks about how to get your changes into an acceptable form. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 2007-04-18 at 13:15 -0700, David Lang wrote: On Wed, 18 Apr 2007, James Morris wrote: On Tue, 17 Apr 2007, Alan Cox wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. since AA defines a whitelist of files that httpd is allowed to access, a comprimised one may be able to mess up it's files, but it's still not going to be able to touch other files on the system. Without security labeling of the objects being accessed, you can't protect against software flaws, which has been a pretty fundamental and widely understood requirement in general computing for at least a decade. this is not true. you don't need to label all object and chunks of memory, you just need to have a way to list (and enforce) the objects and memory that the program is allowed to use. labeling them is one way of doing this, but not the only way. You need a way of providing global and persistent security guarantees for the data, and per-program profiles based on pathname don't get you there. There is no system view in AA, just a bunch of disconnected profiles. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 2007-04-19 at 16:35 +, David Wagner wrote: James Morris wrote: On Wed, 18 Apr 2007, Crispin Cowan wrote: How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? Because you can change the behavior of the application and then bypass policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc. Any halfway decent jail will let you control access to all of those things, thereby preventing an 0wned httpd from breaking out of the jail. (For instance, Janus did. So does Systrace.) Are you saying AppArmor does not allow that kind of control? Specifics would be useful. Just look at their code and their own description of AppArmor. It does not provide that level of control, and by your own metric, it is thus not a halfway decent jail. Which begs the question - if that is the kind of approach you want, why not use a real jail/containers mechanism for it? Also worth noting here is that you have to consider any limited environment as enforcing security policy, and thus its configuration becomes an additional component of security policy. I don't understand what you are saying. Yes, the AppArmor policy file is part of policy. Is that what you mean? I think he means the dependencies on which AppArmor relies, not just its policy, e.g. since it is name-based, it presumes the filesystem namespace has been set up by a trusted agent and is correct. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 20:05 +0200, Andi Kleen wrote: Karl MacMillan [EMAIL PROTECTED] writes: No - the real fix is to change the applications or to run under a policy that confines all applications. Most of the problems with resolv.conf, mtab, etc. stem from admin processes (e.g., editors or shell scripts) all running under the same unconfined domain. In some cases applications need modification as only the application has enough information to determine the correct label. Usually this means preserving labels from input files or separating the output into distinct directories so type transitions or label inheritance will work. restorecond is just a hack not a requirement or a sign that something is wrong with the model. That is why it is a userspace application and not integrated into the kernel mechanism. You nicely show one of the major disadvantages of the label model vs the path model here: it requires modification of a lot of applications. It is true that many applications that already deal with mode bits need to become aware of labels, just as with ACLs, and that this makes it a bit harder and slower to roll out something that is label-based. But the right solution is rarely quick and easy, and a lot of work has already happened to integrate such support into userland. To look at it in a slightly different way, the AA emphasis on not modifying applications could be viewed as a limitation. Ultimately, users have security goals that go beyond just what the OS can directly enforce and at least some applications (notably things like X, D-BUS, PostgreSQL, etc) need to likewise support strong domain separation and controlled information flow through their own internal objects and operations. SELinux provides APIs and infrastructure for such applications, and has already done quite a bit of work in that space (D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have no interest in going there (and would have to recant its emphasis on no application mods to do so). If you actually want to truly confine a desktop application, you can't limit yourself to the kernel. And the label model provides a unifying abstraction for dealing with all of these various objects, whereas the path/natural abstraction model has no unifying abstraction at all. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote: David Safford wrote: On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: On Mon, 16 Apr 2007, John Johansen wrote: Label-based security (exemplified by SELinux, and its predecessors in MLS systems) attaches security policy to the data. As the data flows through the system, the label sticks to the data, and so security policy with respect to this data stays intact. This is a good approach for ensuring secrecy, the kind of problem that intelligence agencies have. Labels are also a good approach for ensuring integrity, which is one of the most fundamental aspects of the security model implemented by SELinux. Some may infer otherwise from your document. In fact, I am not sure how you can provide integrity support without labels. AppArmor confines a process, but does not effectively confine its output files, precisely because the output files are not labeled. Other processes are free to access the unlabeled, potentially malicious output files without restriction. That depends on what you mean by integrity. It is true that AppArmor does not directly manage information flow. AppArmor assumes that if you granted write permission to /etc/resolv.conf, that you meant to do that. Whether any other process is permitted to access /etc/resolv.conf is determined by those other process's respective profiles. Integrity protection requires information flow control; you can't protect a high integrity process from being corrupted by a low integrity process if you don't control the flow of information. Plenty of attacks take the form of a untrusted process injecting data that will ultimately be used by a more trusted process with a surprising side effect. And you can't do information flow control if you can't provide global and persistent protection of the data, which requires labeling it and preserving that label for its lifetime. What AppArmor provides is a way for administrators to confine software that they have to run but do not trust. The use of pathnames means that the administrator can understand the exact meaning of the security policy, without having to do a complete labeling of the file system. The flip side of not managing information flow is that each profile is independent of every other profile. They aren't truly independent; the composition may lead to surprising results where each individual program is confined exactly as you specified, but in combination, one is able to corrupt the higher integrity subject by actions taken by the lower integrity subject. Particularly in the fun area of publically writable directories, where pathnames are largely useless as an indicator. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 2007-04-19 at 20:08 +, David Wagner wrote: Stephen Smalley wrote: Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM Vol 16 No 10) means information flow control, which you have agreed AppArmor does not and cannot provide. Right, that's how I understand it, too. However, I think some more caveats are in order. In all honesty, I don't think SELinux solves Lampson's problem, either. It is useful to distinguish between bit-confinement (confining the flow of information, a la Lampson) vs authority-confinement (confining the flow of privileges and the ability of the untrusted app to cause side effects on the rest of the system). No Linux system provides bit-confinement, if the confined app is malicious. AppArmor does not provide bit-confinement. Neither does SELinux. SELinux can stop some kinds of accidental leakage of secrets, but it cannot prevent deliberate attempts to leak the secrets that are known to malicious apps. The reason is that, in every system under consideration, it is easy for a malicious app to leak any secrets it might have to the outside world by using covert channels (e.g., wall-banging). In practical terms, Lampson's bit-confinement problem is just not solvable. Oh well, so it goes. A good jail needs to provide authority-confinement, but thankfully, it doesn't need to provide bit-confinement. I don't know enough about AppArmor to know whether it is able to do a good job of providing authority-confinement. If it cannot, then it deserves criticism on those grounds. Often the pragmatic solution to the covert channel problem is to ensure that untrusted apps are never given access to critical secrets in the first place. They can't leak something they don't know. This solves the confidentiality problem by avoiding any attempt to tackle the unsolvable bit-confinement problem. Note that the problem of building a good jail is a little different from the information flow control problem. First, I think there is practical value in providing confidentiality control on the overt channels, even if covert channels remain. We have to start somewhere. Second, information flow is not just a confidentiality issue - see my other email. It is quite important as well for integrity, and integrity corruption in order to assume control over a privileged subject or trick it into abusing its power can be done solely via a data channel - it doesn't require explicit flow of authority. Lastly, if you want to judge AA as a jail mechanism, I think you'll find it fails there too. So where does that leave it? An easy-to-use yet inadequate solution for MAC or jail. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 2007-04-19 at 20:54 +, David Wagner wrote: Stephen Smalley wrote: Integrity protection requires information flow control; you can't protect a high integrity process from being corrupted by a low integrity process if you don't control the flow of information. Plenty of attacks take the form of a untrusted process injecting data that will ultimately be used by a more trusted process with a surprising side effect. I don't agree with this blanket statement. In a number of cases of practical interest, useful integrity protection can be achieved without full information flow control. Suppose you have a malicious (low integrity) process A, and a target (high integrity) process B. We want to prevent A from attacking B. One way to do that is to ensure that A has no overt channel it can use to attack process B, by severely restricting A's ability to cause side effects on the rest of the world. This is often sufficient to contain the damage that A can do. If you could do that, I'd call that information flow control - I wasn't saying you had to eliminate covert channels. As you said, we don't deal with those even in SELinux. The point is that AA can't even do that, not only because it has incomplete controls but because it bases its decisions on unreliable identifiers (paths) that doesn't let it provide global and persistent protection of the data. Of course, if the intended functionality of the system requires A to communicate data to B, and if you don't trust B's ability to handle that data carefully enough, and if A is malicious, then you've got a serious problem. But in a number of cases (enough cases to be useful), you can provide a useful level of security without needing information flow control and without needing global, persistent labels. Without a reliable way of identifying the data in a system view, you can't say anything at all about the data flows. The labels provide you with a way of doing that. The paths are ambiguous, highly mutable, and often meaningless (particularly for runtime files, temporary files, etc) from a security pov. Simple example: malicious symlink attacks. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oprofile / selinux / security_port_sid
On Tue, 2007-03-27 at 13:06 +0300, Sami Farin wrote: > is there room for improvement in security_port_sid() ? Yes, lots of room. Also, it won't get called per-packet if you enable secmark (echo 0 > /selinux/compat_net or boot with selinux_compat_net=0 or build with SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT), although that may require updating your policy. > little test with dns queries (dnsfilter (the client) on local host > using poll() and dnscache (the server) using epoll (at max 4000 concurrent > queries): > (stats for only vmlinux) > > CPU: P4 / Xeon, speed 2797.32 MHz (estimated) > Counted GLOBAL_POWER_EVENTS events (time during which processor is not > stopped) with a unit mask of 0x01 (mandatory) count 45000 > Counted FSB_DATA_ACTIVITY events (DRDY or DBSY events on the front side bus) > with a unit mask of 0x03 (multiple flags) count 45000 > Counted BRANCH_RETIRED events (retired branches) with a unit mask of 0x05 > (multiple flags) count 45000 > Counted BRANCH_RETIRED events (retired branches) with a unit mask of 0x0a > (multiple flags) count 45000 > samples %samples %samples %samples % > symbol name > 220663 10.2181 6704 17.9737 5735 7.5171 271.1989 > datagram_poll > 1400866.4869 3239 8.6839 3786 4.9624 241.0657 > sock_poll > 1196365.5399 2172 5.8232 7168 9.3954 241.0657 > do_poll > 1015124.7006 3987 10.6893 812 1.0643 140.6217 > udp_get_port > 71008 3.2881 1017 2.7266 2694 3.5311 397 17.6288 > security_port_sid > 64350 2.9798 144 0.3861 1912 2.5061 6 0.2664 > add_wait_queue > 60815 2.8161 187 0.5014 3246 4.2546 2 0.0888 > remove_wait_queue > 47456 2.1975 1823 4.8875 476 0.6239 311.3766 > udp_v4_lookup_longway > > if dnsfilter had used epoll, security_port_sid would > probably (?) be number one (or two or three) CPU user in kernel. > > also note that 17.6% of mispredicted branches occurr in security_port_sid. > -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oprofile / selinux / security_port_sid
On Tue, 2007-03-27 at 13:06 +0300, Sami Farin wrote: is there room for improvement in security_port_sid() ? Yes, lots of room. Also, it won't get called per-packet if you enable secmark (echo 0 /selinux/compat_net or boot with selinux_compat_net=0 or build with SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT), although that may require updating your policy. little test with dns queries (dnsfilter (the client) on local host using poll() and dnscache (the server) using epoll (at max 4000 concurrent queries): (stats for only vmlinux) CPU: P4 / Xeon, speed 2797.32 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 45000 Counted FSB_DATA_ACTIVITY events (DRDY or DBSY events on the front side bus) with a unit mask of 0x03 (multiple flags) count 45000 Counted BRANCH_RETIRED events (retired branches) with a unit mask of 0x05 (multiple flags) count 45000 Counted BRANCH_RETIRED events (retired branches) with a unit mask of 0x0a (multiple flags) count 45000 samples %samples %samples %samples % symbol name 220663 10.2181 6704 17.9737 5735 7.5171 271.1989 datagram_poll 1400866.4869 3239 8.6839 3786 4.9624 241.0657 sock_poll 1196365.5399 2172 5.8232 7168 9.3954 241.0657 do_poll 1015124.7006 3987 10.6893 812 1.0643 140.6217 udp_get_port 71008 3.2881 1017 2.7266 2694 3.5311 397 17.6288 security_port_sid 64350 2.9798 144 0.3861 1912 2.5061 6 0.2664 add_wait_queue 60815 2.8161 187 0.5014 3246 4.2546 2 0.0888 remove_wait_queue 47456 2.1975 1823 4.8875 476 0.6239 311.3766 udp_v4_lookup_longway if dnsfilter had used epoll, security_port_sid would probably (?) be number one (or two or three) CPU user in kernel. also note that 17.6% of mispredicted branches occurr in security_port_sid. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 2/6] integrity: fs hook placement
On Thu, 2007-03-08 at 12:01 -0600, Serge E. Hallyn wrote: > Quoting Chris Wright ([EMAIL PROTECTED]): > > * Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > > > Are you objecting only to the duplication at the callsites, so that an > > > fsnotify-type of consolidation of security and integrity hooks would be > > > ok? Or are you complaining that the security_inode_setxattr and > > > integrity_inode_setxattr hooks are too similar anyway, and integrity > > > modules should just use some lsm hooks for anything which will be > > > authoritative? > > > > It's duplication of callsites with many identical implementations > > that's the problem. > > Yes it's ugly... > > But I guess it gets a point across :) > > > > (I could see an argument that integirty subsystem should be purely for > > > measuring and hence its hooks should never return a value. Only hitch > > > there is that if integrity subsystem hits ENOMEM it should be able to > > > refuse the action...) > > > > Right, that's what I was expecting to see, just the measurement > > infrastructure. > > So what you are saying is EVM would stay an LSM, with a cooperating > integrity subsystem *just* doing measurements? > > That's kind of what i was expecting too, however that doesn't fit as > well with the idea that an integrity subsystem prevents the need for lsm > stacking. I think the idea was that evm would still be able to enforce > integrity of selinux xattrs without it stack with selinux. So I can see > where this approach came from. The enforcement mechanism should be directly integrated into SELinux, not stacked as a separate module. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][Patch 2/6] integrity: fs hook placement
On Thu, 2007-03-08 at 12:01 -0600, Serge E. Hallyn wrote: Quoting Chris Wright ([EMAIL PROTECTED]): * Serge E. Hallyn ([EMAIL PROTECTED]) wrote: Are you objecting only to the duplication at the callsites, so that an fsnotify-type of consolidation of security and integrity hooks would be ok? Or are you complaining that the security_inode_setxattr and integrity_inode_setxattr hooks are too similar anyway, and integrity modules should just use some lsm hooks for anything which will be authoritative? It's duplication of callsites with many identical implementations that's the problem. Yes it's ugly... But I guess it gets a point across :) (I could see an argument that integirty subsystem should be purely for measuring and hence its hooks should never return a value. Only hitch there is that if integrity subsystem hits ENOMEM it should be able to refuse the action...) Right, that's what I was expecting to see, just the measurement infrastructure. So what you are saying is EVM would stay an LSM, with a cooperating integrity subsystem *just* doing measurements? That's kind of what i was expecting too, however that doesn't fit as well with the idea that an integrity subsystem prevents the need for lsm stacking. I think the idea was that evm would still be able to enforce integrity of selinux xattrs without it stack with selinux. So I can see where this approach came from. The enforcement mechanism should be directly integrated into SELinux, not stacked as a separate module. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] selinux: always initialize arguments to security_sid_to_context (Was: Re: [GIT PULL] audit patches)
On Thu, 2007-02-22 at 13:19 -0800, Andrew Morton wrote:
> > On Thu, 22 Feb 2007 08:22:47 -0500 Stephen Smalley <[EMAIL PROTECTED]>
> > wrote:
> > On Wed, 2007-02-21 at 16:03 -0800, Andrew Morton wrote:
> > >
> > > Looking at the changes to audit_receive_msg():
> > >
> > >
> > > if (sid) {
> > > if (selinux_sid_to_string(
> > > sid, , )) {
> > > audit_log_format(ab,
> > > " ssid=%u", sid);
> > > /* Maybe call audit_panic? */
> > > } else
> > > audit_log_format(ab,
> > > " subj=%s", ctx);
> > > kfree(ctx);
> > > }
> > >
> > > This is assuming that selinux_sid_to_string() always initialises `ctx'.
> > >
> > > But AFAICT there are two error paths in security_sid_to_context() which
> > > forget to do that, so we end up doing kfree(uninitialised-local).
> > >
> > > I'd consider that a shortcoming in security_sid_to_context(), so not a
> > > problem in this patch, as long as people agree with my blaming above.
> >
> > I wouldn't assume that the function initializes an argument if it
> > returns an error, and at least some of the callers (in auditsc.c) appear
> > to correctly initialize ctx to NULL themselves before calling
> > selinux_sid_to_string(). But if you'd prefer the function to always
> > handle it, we can do that.
> >
>
> Well we now have (at least) one caller which assumes that *ctx is
> initialied in error cases.
>
> And I think it's sane to make it do that: safer, and will simplify coding
> in the callers.
Ok, patch below.
Always initialize *scontext and *scontext_len in security_sid_to_context.
Signed-off-by: Stephen Smalley <[EMAIL PROTECTED]>
---
security/selinux/ss/services.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index ca9154d..1e52356 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -609,6 +609,9 @@ int security_sid_to_context(u32 sid, char **scontext, u32
*scontext_len)
struct context *context;
int rc = 0;
+ *scontext = NULL;
+ *scontext_len = 0;
+
if (!ss_initialized) {
if (sid <= SECINITSID_NUM) {
char *scontextp;
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] selinux: always initialize arguments to security_sid_to_context (Was: Re: [GIT PULL] audit patches)
On Thu, 2007-02-22 at 13:19 -0800, Andrew Morton wrote:
On Thu, 22 Feb 2007 08:22:47 -0500 Stephen Smalley [EMAIL PROTECTED]
wrote:
On Wed, 2007-02-21 at 16:03 -0800, Andrew Morton wrote:
Looking at the changes to audit_receive_msg():
if (sid) {
if (selinux_sid_to_string(
sid, ctx, len)) {
audit_log_format(ab,
ssid=%u, sid);
/* Maybe call audit_panic? */
} else
audit_log_format(ab,
subj=%s, ctx);
kfree(ctx);
}
This is assuming that selinux_sid_to_string() always initialises `ctx'.
But AFAICT there are two error paths in security_sid_to_context() which
forget to do that, so we end up doing kfree(uninitialised-local).
I'd consider that a shortcoming in security_sid_to_context(), so not a
problem in this patch, as long as people agree with my blaming above.
I wouldn't assume that the function initializes an argument if it
returns an error, and at least some of the callers (in auditsc.c) appear
to correctly initialize ctx to NULL themselves before calling
selinux_sid_to_string(). But if you'd prefer the function to always
handle it, we can do that.
Well we now have (at least) one caller which assumes that *ctx is
initialied in error cases.
And I think it's sane to make it do that: safer, and will simplify coding
in the callers.
Ok, patch below.
Always initialize *scontext and *scontext_len in security_sid_to_context.
Signed-off-by: Stephen Smalley [EMAIL PROTECTED]
---
security/selinux/ss/services.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index ca9154d..1e52356 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -609,6 +609,9 @@ int security_sid_to_context(u32 sid, char **scontext, u32
*scontext_len)
struct context *context;
int rc = 0;
+ *scontext = NULL;
+ *scontext_len = 0;
+
if (!ss_initialized) {
if (sid = SECINITSID_NUM) {
char *scontextp;
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] audit patches
On Wed, 2007-02-21 at 16:03 -0800, Andrew Morton wrote:
> On Sun, 18 Feb 2007 04:01:27 + Al Viro <[EMAIL PROTECTED]> wrote:
>
> > Misc audit patches (resend again...); the most intrusive one is
> > AUDIT_FD_PAIR,
> > allowing to log descriptor numbers from syscalls that do not return them in
> > usual way (i.e. pipe() and socketpair()). It took some massage of
> > the failure exits in sys_socketpair(); the rest is absolutely trivial.
> > Please, pull from
> > git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current.git/ audit.b37
>
> Please send patches to the list for review if practical? In this case it
> was. I trust davem has had a look at the non-trivial changes to
> sys_socketpair().
>
>
>
> Looking at the changes to audit_receive_msg():
>
>
> if (sid) {
> if (selinux_sid_to_string(
> sid, , )) {
> audit_log_format(ab,
> " ssid=%u", sid);
> /* Maybe call audit_panic? */
> } else
> audit_log_format(ab,
> " subj=%s", ctx);
> kfree(ctx);
> }
>
> This is assuming that selinux_sid_to_string() always initialises `ctx'.
>
> But AFAICT there are two error paths in security_sid_to_context() which
> forget to do that, so we end up doing kfree(uninitialised-local).
>
> I'd consider that a shortcoming in security_sid_to_context(), so not a
> problem in this patch, as long as people agree with my blaming above.
I wouldn't assume that the function initializes an argument if it
returns an error, and at least some of the callers (in auditsc.c) appear
to correctly initialize ctx to NULL themselves before calling
selinux_sid_to_string(). But if you'd prefer the function to always
handle it, we can do that.
>
> The coding style in there is a bit odd-looking.
>
> The new __audit_fd_pair() has unneeded braces in it.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] audit patches
On Wed, 2007-02-21 at 16:03 -0800, Andrew Morton wrote:
On Sun, 18 Feb 2007 04:01:27 + Al Viro [EMAIL PROTECTED] wrote:
Misc audit patches (resend again...); the most intrusive one is
AUDIT_FD_PAIR,
allowing to log descriptor numbers from syscalls that do not return them in
usual way (i.e. pipe() and socketpair()). It took some massage of
the failure exits in sys_socketpair(); the rest is absolutely trivial.
Please, pull from
git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current.git/ audit.b37
Please send patches to the list for review if practical? In this case it
was. I trust davem has had a look at the non-trivial changes to
sys_socketpair().
Looking at the changes to audit_receive_msg():
if (sid) {
if (selinux_sid_to_string(
sid, ctx, len)) {
audit_log_format(ab,
ssid=%u, sid);
/* Maybe call audit_panic? */
} else
audit_log_format(ab,
subj=%s, ctx);
kfree(ctx);
}
This is assuming that selinux_sid_to_string() always initialises `ctx'.
But AFAICT there are two error paths in security_sid_to_context() which
forget to do that, so we end up doing kfree(uninitialised-local).
I'd consider that a shortcoming in security_sid_to_context(), so not a
problem in this patch, as long as people agree with my blaming above.
I wouldn't assume that the function initializes an argument if it
returns an error, and at least some of the callers (in auditsc.c) appear
to correctly initialize ctx to NULL themselves before calling
selinux_sid_to_string(). But if you'd prefer the function to always
handle it, we can do that.
The coding style in there is a bit odd-looking.
The new __audit_fd_pair() has unneeded braces in it.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH -mm] file caps: make on-disk capabilities future-proof
On Mon, 2007-02-19 at 11:01 -0600, Serge E. Hallyn wrote:
> From: Serge E. Hallyn <[EMAIL PROTECTED]>
> Subject: [PATCH -mm] file caps: make on-disk capabilities future-proof
>
> Stephen Smalley has pointed out that the current file capabilities
> will eventually pose a problem.
>
> As the capability set changes and distributions start tagging
> binaries with capabilities, we would like for running an older
> kernel to not necessarily make those binaries unusable. To
> that end,
>
> 1. If capabilities are specified which we don't know
> about, just ignore them, do not return -EPERM as we
> were doing before.
I didn't advocate that change - it is a separate issue from allowing the
capability bitmaps to grow in size in a backward compatible manner. In
the one case, you have a binary that needs a capability that is unknown
to the kernel, so running it could lead to unexpected failure. In the
other case, you simply have a binary labeled by newer userspace with a
newer on-disk representation that supports larger bitmaps, but the
binary might only have capabilities set that are known to the kernel.
> 2. Specify a size with the on-disk capability implementation.
> In this implementation the size is the number of __u32's
> used for each of (eff,perm,inh). For now, sz is 1.
> When we move to 64-bit capabilities, it becomes 2.
You could alternatively split them into separate xattrs, e.g.
security.cap.eff, security.cap.perm, security.cap.inh, and determine the
bitmap size from the xattr length rather than a separate field.
> diff --git a/security/commoncap.c b/security/commoncap.c
> index be86acb..dc8bf4f 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -148,50 +145,65 @@ static int set_file_caps(struct linux_bi
> {
> struct dentry *dentry;
> ssize_t rc;
> - struct vfs_cap_data_disk dcaps;
> + struct vfs_cap_data_disk *dcaps;
> struct vfs_cap_data caps;
> struct inode *inode;
> - int err;
>
> if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID)
> return 0;
>
> dentry = dget(bprm->file->f_dentry);
> inode = dentry->d_inode;
> - if (!inode->i_op || !inode->i_op->getxattr) {
> - dput(dentry);
> - return 0;
> + rc = 0;
> + if (!inode->i_op || !inode->i_op->getxattr)
> + goto out;
> +
> + rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS, NULL, 0);
> + if (rc == -ENODATA) {
> + rc = 0;
> + goto out;
> + }
I'd allocate an initial buffer with an expected size and try first to
avoid always having to make the two ->getxattr calls in the common case.
> + if (rc < 0)
> + goto out;
> + if (rc < sizeof(struct vfs_cap_data_disk)) {
You could make this a bit stricter, as you know that it will have at
least three additional u32 values beyond the header.
> + rc = -EINVAL;
> + goto out;
> + }
> +
> + dcaps = kmalloc(rc, GFP_KERNEL);
> + if (!dcaps) {
> + rc = -ENOMEM;
> + goto out;
> + }
> + rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS, dcaps,
> + XATTR_CAPS_SZ);
I'm confused - you just asked for the actual length of the xattr and
allocated a buffer for it, and then don't use the length in this second
call to ->getxattr. And since you said you were organizing it as
eff[0..sz-1],perm[0..sz-1],inh[0..sz-1], you do need to read the entire
thing to get all three values even if you only use the lower 32 bits of
each. Or if you change the organization to avoid the need to read the
entire thing, you don't need the first getxattr call at all, and you
need to change how cap_from_disk extracts the values.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH -mm] file caps: make on-disk capabilities future-proof
On Mon, 2007-02-19 at 11:01 -0600, Serge E. Hallyn wrote:
From: Serge E. Hallyn [EMAIL PROTECTED]
Subject: [PATCH -mm] file caps: make on-disk capabilities future-proof
Stephen Smalley has pointed out that the current file capabilities
will eventually pose a problem.
As the capability set changes and distributions start tagging
binaries with capabilities, we would like for running an older
kernel to not necessarily make those binaries unusable. To
that end,
1. If capabilities are specified which we don't know
about, just ignore them, do not return -EPERM as we
were doing before.
I didn't advocate that change - it is a separate issue from allowing the
capability bitmaps to grow in size in a backward compatible manner. In
the one case, you have a binary that needs a capability that is unknown
to the kernel, so running it could lead to unexpected failure. In the
other case, you simply have a binary labeled by newer userspace with a
newer on-disk representation that supports larger bitmaps, but the
binary might only have capabilities set that are known to the kernel.
2. Specify a size with the on-disk capability implementation.
In this implementation the size is the number of __u32's
used for each of (eff,perm,inh). For now, sz is 1.
When we move to 64-bit capabilities, it becomes 2.
You could alternatively split them into separate xattrs, e.g.
security.cap.eff, security.cap.perm, security.cap.inh, and determine the
bitmap size from the xattr length rather than a separate field.
diff --git a/security/commoncap.c b/security/commoncap.c
index be86acb..dc8bf4f 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -148,50 +145,65 @@ static int set_file_caps(struct linux_bi
{
struct dentry *dentry;
ssize_t rc;
- struct vfs_cap_data_disk dcaps;
+ struct vfs_cap_data_disk *dcaps;
struct vfs_cap_data caps;
struct inode *inode;
- int err;
if (bprm-file-f_vfsmnt-mnt_flags MNT_NOSUID)
return 0;
dentry = dget(bprm-file-f_dentry);
inode = dentry-d_inode;
- if (!inode-i_op || !inode-i_op-getxattr) {
- dput(dentry);
- return 0;
+ rc = 0;
+ if (!inode-i_op || !inode-i_op-getxattr)
+ goto out;
+
+ rc = inode-i_op-getxattr(dentry, XATTR_NAME_CAPS, NULL, 0);
+ if (rc == -ENODATA) {
+ rc = 0;
+ goto out;
+ }
I'd allocate an initial buffer with an expected size and try first to
avoid always having to make the two -getxattr calls in the common case.
+ if (rc 0)
+ goto out;
+ if (rc sizeof(struct vfs_cap_data_disk)) {
You could make this a bit stricter, as you know that it will have at
least three additional u32 values beyond the header.
+ rc = -EINVAL;
+ goto out;
+ }
+
+ dcaps = kmalloc(rc, GFP_KERNEL);
+ if (!dcaps) {
+ rc = -ENOMEM;
+ goto out;
+ }
+ rc = inode-i_op-getxattr(dentry, XATTR_NAME_CAPS, dcaps,
+ XATTR_CAPS_SZ);
I'm confused - you just asked for the actual length of the xattr and
allocated a buffer for it, and then don't use the length in this second
call to -getxattr. And since you said you were organizing it as
eff[0..sz-1],perm[0..sz-1],inh[0..sz-1], you do need to read the entire
thing to get all three values even if you only use the lower 32 bits of
each. Or if you change the organization to avoid the need to read the
entire thing, you don't need the first getxattr call at all, and you
need to change how cap_from_disk extracts the values.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] selinux: Enhance selinux to always ignore private inodes.
On Thu, 2007-02-08 at 16:02 -0700, Eric W. Biederman wrote: > From: Stephen Smalley <[EMAIL PROTECTED]> > > Hmmm...turns out to not be quite enough, as the /proc/sys inodes aren't > truly private to the fs, so we can run into them in a variety of > security hooks beyond just the inode hooks, such as > security_file_permission (when reading and writing them via the vfs > helpers), security_sb_mount (when mounting other filesystems on > directories in proc like binfmt_misc), and deeper within the security > module itself (as in flush_unauthorized_files upon inheritance across > execve). So I think we have to add an IS_PRIVATE() guard within > SELinux, as below. Note however that the use of the private flag here > could be confusing, as these inodes are _not_ private to the fs, are > exposed to userspace, and security modules must implement the sysctl > hook to get any access control over them. Signed-off-by: Stephen Smalley <[EMAIL PROTECTED]> > Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> > > --- > security/selinux/hooks.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > index de16b9f..ff9fccc 100644 > --- a/security/selinux/hooks.c > +++ b/security/selinux/hooks.c > @@ -1077,6 +1077,9 @@ static int inode_has_perm(struct task_struct *tsk, > struct inode_security_struct *isec; > struct avc_audit_data ad; > > + if (unlikely (IS_PRIVATE (inode))) > + return 0; > + > tsec = tsk->security; > isec = inode->i_security; > -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] sysctl: Fix the selinux_sysctl_get_sid
On Thu, 2007-02-08 at 15:55 -0700, Eric W. Biederman wrote:
> I goofed and when reenabling the fine grained selinux labels for
> sysctls and forgot to add the "/sys" prefix before consulting
> the policy database. When computing the same path using
> proc_dir_entries we got the "/sys" for free as it was part
> of the tree, but it isn't true for clt_table trees.
>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Acked-by: Stephen Smalley <[EMAIL PROTECTED]>
> ---
> security/selinux/hooks.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 47fb937..de16b9f 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1445,6 +1445,12 @@ static int selinux_sysctl_get_sid(ctl_table *table,
> u16 tclass, u32 *sid)
> path = end;
> table = table->parent;
> }
> + buflen -= 4;
> + if (buflen < 0)
> + goto out_free;
> + end -= 4;
> + memcpy(end, "/sys", 4);
> + path = end;
> rc = security_genfs_sid("proc", path, tclass, sid);
> out_free:
> free_page((unsigned long)buffer);
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] sysctl: Fix the selinux_sysctl_get_sid
On Thu, 2007-02-08 at 15:55 -0700, Eric W. Biederman wrote: I goofed and when reenabling the fine grained selinux labels for sysctls and forgot to add the /sys prefix before consulting the policy database. When computing the same path using proc_dir_entries we got the /sys for free as it was part of the tree, but it isn't true for clt_table trees. Signed-off-by: Eric W. Biederman [EMAIL PROTECTED] Acked-by: Stephen Smalley [EMAIL PROTECTED] --- security/selinux/hooks.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 47fb937..de16b9f 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -1445,6 +1445,12 @@ static int selinux_sysctl_get_sid(ctl_table *table, u16 tclass, u32 *sid) path = end; table = table-parent; } + buflen -= 4; + if (buflen 0) + goto out_free; + end -= 4; + memcpy(end, /sys, 4); + path = end; rc = security_genfs_sid(proc, path, tclass, sid); out_free: free_page((unsigned long)buffer); -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] selinux: Enhance selinux to always ignore private inodes.
On Thu, 2007-02-08 at 16:02 -0700, Eric W. Biederman wrote: From: Stephen Smalley [EMAIL PROTECTED] Hmmm...turns out to not be quite enough, as the /proc/sys inodes aren't truly private to the fs, so we can run into them in a variety of security hooks beyond just the inode hooks, such as security_file_permission (when reading and writing them via the vfs helpers), security_sb_mount (when mounting other filesystems on directories in proc like binfmt_misc), and deeper within the security module itself (as in flush_unauthorized_files upon inheritance across execve). So I think we have to add an IS_PRIVATE() guard within SELinux, as below. Note however that the use of the private flag here could be confusing, as these inodes are _not_ private to the fs, are exposed to userspace, and security modules must implement the sysctl hook to get any access control over them. Signed-off-by: Stephen Smalley [EMAIL PROTECTED] Signed-off-by: Eric W. Biederman [EMAIL PROTECTED] --- security/selinux/hooks.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index de16b9f..ff9fccc 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -1077,6 +1077,9 @@ static int inode_has_perm(struct task_struct *tsk, struct inode_security_struct *isec; struct avc_audit_data ad; + if (unlikely (IS_PRIVATE (inode))) + return 0; + tsec = tsk-security; isec = inode-i_security; -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] sysctl: Restore the selinux path based label lookup for sysctls.
On Thu, 2007-02-08 at 10:53 -0700, Eric W. Biederman wrote: > Stephen Smalley <[EMAIL PROTECTED]> writes: > > > > > Hmmm...turns out to not be quite enough, as the /proc/sys inodes aren't > > truly private to the fs, so we can run into them in a variety of > > security hooks beyond just the inode hooks, such as > > security_file_permission (when reading and writing them via the vfs > > helpers), security_sb_mount (when mounting other filesystems on > > directories in proc like binfmt_misc), and deeper within the security > > module itself (as in flush_unauthorized_files upon inheritance across > > execve). So I think we have to add an IS_PRIVATE() guard within > > SELinux, as below. Note however that the use of the private flag here > > could be confusing, as these inodes are _not_ private to the fs, are > > exposed to userspace, and security modules must implement the sysctl > > hook to get any access control over them. > > Agreed, the naming is confusing, and using private here doesn't quite > feel right. > > A practical question is: Will we ever encounter these inodes > in the inode_init() path from superblock_init? Possibly, during setup upon initial policy load (initiated by /sbin/init these days) from selinux_complete_init, as early userspace may have already been accessing them. > If all of the accesses > that we care about go through inode_doinit_with_dentry we can just > walk the dcache to get the names, and that should work for the normal > proc case as well. Walking the proc_dir_entry tree (or the ctl_table tree) is preferable as it is a stable, user-immutable representation. Also avoids taking the dcache lock. > A somewhat related question: How do you handle security labels for > sysfs? No fine grained security yet. Right, they are all mapped to a single label presently. I was thinking of handling that from userspace after introducing a setxattr handler for sysfs and a way to preserve the SID on the entry (likely caching it in the sysfs_dirent and propagating that to the inode when the inode is populated from the sysfs_dirent). Then early userspace could walk sysfs and apply finer-grained labeling from a configuration. > If it doesn't look easy to solve this another way I will certainly > go with marking the inodes private. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] sysctl: Restore the selinux path based label lookup for sysctls.
On Wed, 2007-02-07 at 15:21 -0700, Eric W. Biederman wrote:
> Stephen Smalley <[EMAIL PROTECTED]> writes:
>
> > Actually, on further inspection, it looks like the real issue is the
> > "path" name generation; "cat /proc/sys/kernel/modprobe" yields a call to
> > security_genfs_sid() with just "/modprobe" rather than the expected
> > "/sys/kernel/modprobe". Which likewise leaves us with the generic proc
> > label, just as with the inode permission check, so I end up seeing
> > checks against it only.
>
> Ok. It looks like two silly thing are going on here.
> I failed to register the root sysctl table, so none of the parent
> pointers got set.
>
> I didn't prepend /sys in the compatibility code, so for something with
> the parent pointers set you would have gotten "/kernel/modprobe" instead
> of /sys/kernel/modprobe"
>
> Sorry about that.
>
> I think the patch below will fix it.
Yes, thanks - this appears to correct the name generation and thus the
resulting SID computation for the selinux sysctl checks.
> Eric
>
> diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
> index 24f36f1..f316854 100644
> --- a/include/linux/sysctl.h
> +++ b/include/linux/sysctl.h
> @@ -929,8 +929,6 @@ extern struct ctl_table_header *sysctl_head_next(struct
> ctl_table_header *prev);
> extern void sysctl_head_finish(struct ctl_table_header *prev);
> extern int sysctl_perm(struct ctl_table *table, int op);
>
> -extern void sysctl_init(void);
> -
> typedef struct ctl_table ctl_table;
>
> typedef int ctl_handler (ctl_table *table, int __user *name, int nlen,
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 0a5499f..0bb2c5f 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1241,6 +1241,14 @@ static void sysctl_set_parent(struct ctl_table
> *parent, struct ctl_table *table)
> }
> }
>
> +static __init int sysctl_init(void)
> +{
> + sysctl_set_parent(NULL, root_table);
> + return 0;
> +}
> +
> +core_initcall(sysctl_init);
> +
> /**
> * register_sysctl_table - register a sysctl hierarchy
> * @table: the top-level table structure
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index c17a8dd..aad2697 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1452,6 +1452,12 @@ static int selinux_sysctl_get_sid(ctl_table *table,
> u16 tclass, u32 *sid)
> path = end;
> table = table->parent;
> }
> + buflen -= 4;
> + if (buflen < 0)
> + goto out_free;
> + end -= 4;
> + memcpy(end, "/sys", 4);
> + path = end;
> rc = security_genfs_sid("proc", path, tclass, sid);
> out_free:
> free_page((unsigned long)buffer);
>
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] sysctl: Restore the selinux path based label lookup for sysctls.
On Wed, 2007-02-07 at 18:57 -0700, Eric W. Biederman wrote: > Stephen Smalley <[EMAIL PROTECTED]> writes: > > > > > One related but separate issue is that the /proc/sys inode labeling is > > also affected by the sysctl patch series. Those inodes used to be > > labeled by selinux_proc_get_sid (from selinux_d_instantiate), but that > > no longer works, so they now fall back to the superblock SID (generic > > proc label). That changes the inode permission checks on an attempt to > > access a /proc/sys node and will likely cause denials under current > > policy for confined domains since one wouldn't generally be writing to > > the generic proc label. If you always called sysctl_perm from the proc > > sysctl code, we could possibly dispense with inode permission checking > > on those inodes, e.g. marking them private. > > Like this? > > It seems a little weird but I'm happy with it if you are. > > Eric > > diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c > index b9d59c0..7d6f7c7 100644 > --- a/fs/proc/proc_sysctl.c > +++ b/fs/proc/proc_sysctl.c > @@ -47,6 +47,7 @@ static struct inode *proc_sys_make_inode(struct inode *dir, > struct ctl_table *ta > inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME; > inode->i_op = _sys_inode_operations; > inode->i_fop = _sys_file_operations; > + inode->i_flags |= S_PRIVATE; /* tell selinux to ignore this inode */ > proc_sys_refresh_inode(inode, table); > out: > return inode; Hmmm...turns out to not be quite enough, as the /proc/sys inodes aren't truly private to the fs, so we can run into them in a variety of security hooks beyond just the inode hooks, such as security_file_permission (when reading and writing them via the vfs helpers), security_sb_mount (when mounting other filesystems on directories in proc like binfmt_misc), and deeper within the security module itself (as in flush_unauthorized_files upon inheritance across execve). So I think we have to add an IS_PRIVATE() guard within SELinux, as below. Note however that the use of the private flag here could be confusing, as these inodes are _not_ private to the fs, are exposed to userspace, and security modules must implement the sysctl hook to get any access control over them. diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 65fb5e8..21bf2f0 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -1078,6 +1077,9 @@ static int inode_has_perm(struct task_st struct inode_security_struct *isec; struct avc_audit_data ad; + if (unlikely (IS_PRIVATE (inode))) + return 0; + tsec = tsk->security; isec = inode->i_security; -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
