On Thu, Oct 25, 2007 at 11:40:24PM -0700, [email protected] wrote:
Sorry this got dropped some how.
This submission of the AppArmor security module is based against -mm.
Any comments and feedback to improve implementation are appreciated.
The patch series consists of five areas:
(1) Pass struct vfsmount through to LSM hooks.
(2) Fixes and improvements to __d_path():
(a) make it unambiguous and exclude unreachable paths from
/proc/mounts,
(b) make its result consistent in the face of remounts,
(c) introduce d_namespace_path(), a variant of d_path that goes up
to the namespace root instead of the chroot.
(d) the behavior of d_path() and getcwd() remain unchanged, and
there is no hidding of unreachable paths in /proc/mounts. The
patches addressing these have been seperated from the AppArmor
submission and will be introduced at a later date.
Part (a) has been in the -mm tree for a while; this series includes
an updated copy of the -mm patch. Parts (b) and (c) shouldn't be too
controversial.
(3) Be able to distinguish file descriptor access from access by name
in LSM hooks.
Applications expect different behavior from file descriptor
accesses and accesses by name in some cases. We need to pass this
information down the LSM hooks to allow AppArmor to tell which is
which.
(4) Convert the selinux sysctl pathname computation code into a standalone
function.
(5) The AppArmor LSM itself.
(See below.)
A tarball of the kernel patches, base user-space utilities, example
profiles, and technical documentation (including a walk-through) are
available at:
http://forgeftp.novell.com/apparmor/LKML_Submission-Oct-07/
Only the most recent features are covered in brief here for a more
complete explaination please refere to the technical documentation.
Changes since previous submission
- fix wrong error code for failed pathname
- fix change_profile ref counting bug
- fix change_hat missing mandatory profile bug
- file rules can now be specified in permission first order
- add append permission which is subset of write permission
- add lock mediation for finer grained control, previously locking only
required access right to a file
- added simple Network toggles for course network mediation
- added profile namespaces (currently only available through change_profile)
- added DAC style permissions
- added the ability to specify hard link rules using location pairs
- added per profile namespace default profile
- added pix transition mode
- builtin only
Outstanding Issues
- use of d_namespace_path and buffer allocation to obtain a pathname for
mediation.
- conditional passing of the vfsmnt. This can be addressed by rebasing
on the lookup intent patches but that has not been done for this
submission.
- ipc and signal mediation are a wip and not included.
- fine grained network mediation
- system confinement from boot is a wip and not included.
- documentation needs to be updated to include newest features
Explanation of new features
The user side policy parser now support specifying file rules with
permissions specified before the path expression; the old syntax is
still supported.
eg.
r /etc/shadow,
Profile Namespaces
AppArmor now allows for profile sets to exist in seperate namespaces.
This is the first step in allowing AppArmor to have different policy,
per container.
Profile namespaces currently can only be set through change_profile.
Confined tasks inherit the namespace of their parent.
User, Group, Other permission masks
AppArmor now allows file permissions to be specified at the user,
group, and other level similar to DAC. For each permission set of user,
group, other the full AppArmor permission set (rwaxlmk) are provided.
The permission group to apply is determined using the fsuid.
The permission sets are seperated using the : character. This deviates
from dac but the permission sets are wider, and do not have a set order.
If any distinct user:group:other permissions are being expressed then all
of the user:group:other permissions for the rule must be expressed. That
is to say just writing rw, does not provide user rw, and rw:r does not
provide user and group permissions.
eg.
/foo rw:r:r, # give user rw, group and other r
/foo rw::, # give user rw, no permissions to group and other
/foo :r:r, # give group and other read permissions
/foo ::r, # give other read permissions
Traditional AppArmor rules are still supported user side and are mapped
to the same permission in each of user, group and other. So
/foo rwpx,
is the same as
/foo rwpx:rwpx:rwpx,
For a given rule user, group, other must use the same exec qualifier.
Multiple rules can be used to specify different exec qualifiers for
each of user, group, or other for a given match.
eg.
/bin/foo px::,
/bin/foo :ix:ix,
The link permission is determined by the target files ownership this
allows for writting rules that enforce openwall style link restrictions.
/** l::, #allow linking to any file owned by the user
The user, group, other permission masks can be written in a permission
first manner as well.
Link rules
Dedicated link rules using source and destination have been added,
to allow for tighter control of hard links when necessary.
eg.
link /linkname -> /targetname,
if user:group:other link specification is desired then a user:group:other
mask containing only the link perm in the appropriate positions can be
specified. The permission group to apply is determined by the target
and the fsuid.
eg.
link l:: /linkname -> /targetname, # allow if /targetname owned by user
or
l:: /linkname -> /targetname,
Both the linkname and the target support full AppArmor globbing.
link l:: /** -> /**, # allow any link to target owned by user
Traditional AA style links are still supported and are mapped by the
parser into the newer link pair for the kernel.
/linkname rwl,
is mapped to
link /linkname -> /**,
> --
>
> -
> 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/
On Thu, 25 Oct 2007 23:40:24 -0700
[email protected] wrote:
before going into the LSM / security side of things, I'd like to get
the VFS guys to look at your VFS interaction code.
In addition, I'd like to ask you to put a file in Documentation/
somewhere that describes what AppArmor is intended security protection
is (it's different from SELinux for sure for example); by having such a
document for each LSM user, end users and distros can make a more
informed decision which module suits their requirements... and it also
makes it possible to look at the implementation to see if it has gaps
to the intent, without getting into a pissing contest about which
security model is better; but unless the security goals are explicitly
described that's a trap that will keep coming back... so please spend
some time on getting a good description going here..
--
If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Fri, Oct 26, 2007 at 07:37:21AM -0700, Arjan van de Ven wrote:
> On Thu, 25 Oct 2007 23:40:24 -0700
> [email protected] wrote:
>
> before going into the LSM / security side of things, I'd like to get
> the VFS guys to look at your VFS interaction code.
>
yes, the vfs interaction definitely need their review.
> In addition, I'd like to ask you to put a file in Documentation/
> somewhere that describes what AppArmor is intended security protection
> is (it's different from SELinux for sure for example); by having such a
> document for each LSM user, end users and distros can make a more
> informed decision which module suits their requirements... and it also
> makes it possible to look at the implementation to see if it has gaps
> to the intent, without getting into a pissing contest about which
> security model is better; but unless the security goals are explicitly
> described that's a trap that will keep coming back... so please spend
> some time on getting a good description going here..
>
yes this is needed and a good idea in general
thanks
john
On Fri, 26 Oct 2007 11:34:48 -0700
John Johansen <[email protected]> wrote:
> On Fri, Oct 26, 2007 at 07:37:21AM -0700, Arjan van de Ven wrote:
> > On Thu, 25 Oct 2007 23:40:24 -0700
> > [email protected] wrote:
> >
> > before going into the LSM / security side of things, I'd like to get
> > the VFS guys to look at your VFS interaction code.
> >
> yes, the vfs interaction definitely need their review.
>
> > In addition, I'd like to ask you to put a file in Documentation/
> > somewhere that describes what AppArmor is intended security
> > protection is (it's different from SELinux for sure for example);
> > by having such a document for each LSM user, end users and distros
> > can make a more informed decision which module suits their
> > requirements... and it also makes it possible to look at the
> > implementation to see if it has gaps to the intent, without getting
> > into a pissing contest about which security model is better; but
> > unless the security goals are explicitly described that's a trap
> > that will keep coming back... so please spend some time on getting
> > a good description going here..
> >
> yes this is needed and a good idea in general
>
would you mind posting your first stab at this to the list shortly,
because without that it's nearly impossible to review your patchkit in
a sensible way...
On Friday 26 October 2007 16:37, Arjan van de Ven wrote:
> In addition, I'd like to ask you to put a file in Documentation/
> somewhere that describes what AppArmor is intended security protection
> is (it's different from SELinux for sure for example); by having such a
> document for each LSM user, end users and distros can make a more
> informed decision which module suits their requirements... and it also
> makes it possible to look at the implementation to see if it has gaps
> to the intent, without getting into a pissing contest about which
> security model is better; but unless the security goals are explicitly
> described that's a trap that will keep coming back... so please spend
> some time on getting a good description going here..
Hmm, I agree that it makes sense to give a short overview of each LSM. A
description of the AppArmor model and implementation can be found in the
directory that John referred to actually. I'm unsure how much of that makes
sense under Documentation/ -- what do you think?
http://forgeftp.novell.com/apparmor/LKML_Submission-Oct-07/techdoc.pdf
I guess actual end user information doesn't belong in the kernel sources; that
really seems wrong.
Thanks,
Andreas
On Fri, 26 Oct 2007 22:44:56 +0200
Andreas Gruenbacher <[email protected]> wrote:
> On Friday 26 October 2007 16:37, Arjan van de Ven wrote:
> > In addition, I'd like to ask you to put a file in Documentation/
> > somewhere that describes what AppArmor is intended security
> > protection is (it's different from SELinux for sure for example);
> > by having such a document for each LSM user, end users and distros
> > can make a more informed decision which module suits their
> > requirements... and it also makes it possible to look at the
> > implementation to see if it has gaps to the intent, without getting
> > into a pissing contest about which security model is better; but
> > unless the security goals are explicitly described that's a trap
> > that will keep coming back... so please spend some time on getting
> > a good description going here..
>
> Hmm, I agree that it makes sense to give a short overview of each
> LSM. A description of the AppArmor model and implementation can be
> found in the directory that John referred to actually. I'm unsure how
> much of that makes sense under Documentation/ -- what do you think?
>
> http://forgeftp.novell.com/apparmor/LKML_Submission-Oct-07/techdoc.pdf
>
> I guess actual end user information doesn't belong in the kernel
> sources; that really seems wrong.
>
My main concern for now is a description of what it tries to protect
against/in what cases you would expect to use it. THe reason for asking
this explicitly is simple: Until now the LSM discussions always ended
up in a nasty mixed up mess around disagreeing on the theoretical model
of what to protect against and the actual implementation of the threat
protection. THe only way I can think of to get out of this mess is to
have the submitter of the security model give a description of what his
protection model is (and unless it's silly, not argue about that), and
then only focus on how the code manages to achieve this model, to make
sure there's no big gaps in it, within its own goals/reference.
On the first part (discussion of the model) I doubt we can get people
to agree, that's pretty much phylosophical... on the second part (how
well the code/design lives up to its own goals) the analysis can be
objective and technical.
--
If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Friday 26 October 2007 23:13, Arjan van de Ven wrote:
> My main concern for now is a description of what it tries to protect
> against/in what cases you would expect to use it.
Okay, I see what you mean. Thanks.
Arjan van de Ven wrote:
> My main concern for now is a description of what it tries to protect
> against/in what cases you would expect to use it. THe reason for asking
> this explicitly is simple: Until now the LSM discussions always ended
> up in a nasty mixed up mess around disagreeing on the theoretical model
> of what to protect against and the actual implementation of the threat
> protection. THe only way I can think of to get out of this mess is to
> have the submitter of the security model give a description of what his
> protection model is (and unless it's silly, not argue about that), and
> then only focus on how the code manages to achieve this model, to make
> sure there's no big gaps in it, within its own goals/reference.
>
I really, really like this proposal. It is essentially what I have
always wanted.
> On the first part (discussion of the model) I doubt we can get people
> to agree, that's pretty much phylosophical... on the second part (how
> well the code/design lives up to its own goals) the analysis can be
> objective and technical.
>
I will try to do that as soon as possible. While I will strive to be
both clear and precise, achieving both is challenging. So, if someone
discovers a mis-match between the description and the code, would a
patch to the description be an acceptable resolution, if it did not
render the model silly?
Crispin
--
Crispin Cowan, Ph.D. http://mercenarylinux.com/
Itanium. Vista. GPLv3. Complexity at work
On Fri, 26 Oct 2007 15:16:53 -0700
Crispin Cowan <[email protected]> wrote:
>
> > On the first part (discussion of the model) I doubt we can get
> > people to agree, that's pretty much phylosophical... on the second
> > part (how well the code/design lives up to its own goals) the
> > analysis can be objective and technical.
> >
> I will try to do that as soon as possible. While I will strive to be
> both clear and precise, achieving both is challenging. So, if someone
> discovers a mis-match between the description and the code, would a
> patch to the description be an acceptable resolution, if it did not
> render the model silly?
>
I think it's entirely reasonable that if it turns out that the code
can't do a certain aspect of the envisioned security (eg not just a
code bug but a design level issue), the answer is to adjust the
vision...
--
If you want to reach me at my work email, use [email protected]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Fri, Oct 26, 2007 at 07:37:21AM -0700, Arjan van de Ven wrote:
> before going into the LSM / security side of things, I'd like to get
> the VFS guys to look at your VFS interaction code.
It's been NACKed a few times, and just reposting it won't help.
On Saturday 27 October 2007 22:47, Christoph Hellwig wrote:
> On Fri, Oct 26, 2007 at 07:37:21AM -0700, Arjan van de Ven wrote:
> > before going into the LSM / security side of things, I'd like to get
> > the VFS guys to look at your VFS interaction code.
>
> It's been NACKed a few times, and just reposting it won't help.
Let me repeat what I have said before in another context. The past discussions
on linux-kernel were useful for a while, and we got constructive feedback
which we could act upon, but then the feedback became very non-constructive
again, and you NACKed patches without giving any good reasons. I have asked
for specific feedback but didn't get any in:
- Rejecting the vfsmount additions,
http://marc.info/?l=linux-kernel&m=118350187712375
- VFS layering fuck-up accusation,
http://marc.info/?l=linux-kernel&m=118348050804600
So can we pick up things there again, and have a real discussion about the
things you criticize?
Thanks,
Andreas