|
|
Subscribe / Log in / New account

AppArmor set to be merged for 2.6.36

From:  James Morris <jmorris-AT-namei.org>
To:  linux-kernel-AT-vger.kernel.org
Subject:  Preview of changes to the Security susbystem for 2.6.36
Date:  Fri, 30 Jul 2010 18:59:27 +1000 (EST)
Message-ID:  <alpine.LRH.2.00.1007301852110.14431@tundra.namei.org>
Cc:  linux-security-module-AT-vger.kernel.org, linux-fsdevel-AT-vger.kernel.org
Archive‑link:  Article

The following is a summary of changes to the security subsystem for the 
2.6.36 kernel, which may be found in my development tree at:

git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next

One issue which needs to be addressed is to confirm that there is 
consensus on the new Yama LSM module.  I had thought there was, based on 
list discussion, but have since had differing feedback.

----

Arnd Bergmann (2):
      ima: use generic_file_llseek for securityfs
      selinux: use generic_file_llseek

Chihau Chau (1):
      Security: capability: code style issue

Dan Carpenter (9):
      smack: opt_dentry is never null in in smack_d_instantiate()
      KEYS: Propagate error code instead of returning -EINVAL
      selinux: cleanup return codes in avtab_read_item()
      selinux: propagate error codes in cond_read_list()
      selinux: fix error codes in cond_read_av_list()
      selinux: fix error codes in cond_read_node()
      selinux: fix error codes in cond_policydb_init()
      selinux: fix error codes in cond_read_bool()
      selinux: fix error codes in symtab_init()

David Howells (3):
      KEYS: Authorise keyctl_set_timeout() on a key if we have its authorisation key
      KEYS: Make /proc/keys check to see if a key is possessed before security check
      KEYS: Use the variable 'key' in keyctl_describe_key()

Eric Paris (8):
      SELinux: seperate range transition rules to a seperate function
      SELinux: move genfs read to a separate function
      SELinux: break ocontext reading into a separate function
      vfs: re-introduce MAY_CHDIR
      security: make LSMs explicitly mask off permissions
      SELinux: special dontaudit for access checks
      selinux: place open in the common file perms
      SELinux: Move execmod to the common perms

James Morris (3):
      Merge branch 'next-queue' into next
      AppArmor: update path_truncate method to latest version
      Merge branch 'master' into next-preview

John Johansen (14):
      AppArmor: misc. base functions and defines
      AppArmor: basic auditing infrastructure.
      AppArmor: contexts used in attaching policy to system objects
      AppArmor: dfa match engine
      AppArmor: userspace interfaces
      AppArmor: file enforcement routines
      AppArmor: functions for domain transitions
      AppArmor: update Maintainer and Documentation
      AppArmor: Enable configuring and building of the AppArmor security module
      AppArmor: LSM interface, and security module initialization
      AppArmor: mediation of non file objects
      AppArmor: policy routines for loading and unpacking policy
      AppArmor: core policy routines
      AppArmor: Enable configuring and building of the AppArmor security module

Justin P. Mattock (1):
      KEYS: Reinstate lost passing of process keyring ID in call_sbin_request_key()

Kees Cook (3):
      security: Yama LSM
      Yama: turn process ancestry check into function
      Yama: verify inode is symlink to avoid bind mounts

Mimi Zohar (1):
      security: move LSM xattrnames to xattr.h

Paul E. McKenney (1):
      selinux: remove all rcu head initializations

Paul Moore (5):
      selinux: Set the peer label correctly on connected UNIX domain sockets
      selinux: Consolidate sockcreate_sid logic
      selinux: Shuffle the sk_security_struct alloc and free routines
      selinux: Convert socket related access controls to use socket labels
      selinux: Use current_security() when possible

Rajiv Andrade (1):
      tpm_tis: fix subsequent suspend failures

Tetsuo Handa (42):
      TOMOYO: Add numeric values grouping support.
      TOMOYO: Use structure for passing common arguments.
      TOMOYO: Split file access control functions by type of parameters.
      TOMOYO: Add mount restriction.
      TOMOYO: Add interactive enforcing mode.
      TOMOYO: Split files into some pieces.
      LSM: Remove unused arguments from security_path_truncate().
      TOMOYO: Several fixes for TOMOYO's management programs.
      TOMOYO: Support longer pathname.
      TOMOYO: Allow wildcard for execute permission.
      TOMOYO: Add pathname aggregation support.
      TOMOYO: Update profile structure.
      TOMOYO: Use callback for updating entries.
      TOMOYO: Use common structure for list element.
      TOMOYO: Use callback for updating entries.
      TOMOYO: Use common code for garbage collection.
      TOMOYO: Use common code for open and mkdir etc.
      TOMOYO: Pass parameters via structure.
      TOMOYO: Use callback for permission check.
      TOMOYO: Rename symbols.
      TOMOYO: Loosen parameter check for mount operation.
      TOMOYO: Remove wrapper function for reading keyword.
      TOMOYO: Merge functions.
      TOMOYO: Make read function to void.
      TOMOYO: Pass "struct list_head" rather than "void *".
      TOMOYO: Merge tomoyo_path_group and tomoyo_number_group
      TOMOYO: Use array of "struct list_head".
      TOMOYO: Aggregate reader functions.
      TOMOYO: Merge path_group and number_group.
      TOMOYO: Remove alias keyword.
      TOMOYO: Use common code for domain transition control.
      TOMOYO: Change list iterator.
      TOMOYO: Allow reading only execute permission.
      TOMOYO: Use common code for policy reading.
      TOMOYO: Copy directly to userspace buffer.
      TOMOYO: Small cleanup.
      TOMOYO: Rename symbols.
      TOMOYO: Add missing poll() hook.
      TOMOYO: Explicitly set file_operations->llseek pointer.
      TOMOYO: Fix quota check.
      TOMOYO: Update version to 2.3.0
      TOMOYO: Use pathname specified by policy rather than execve()

Tvrtko Ursulin (1):
      securityfs: Drop dentry reference count when mknod fails



-- 
James Morris
<jmorris@namei.org>



to post comments

AppArmor set to be merged for 2.6.36

Posted Jul 30, 2010 19:57 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

This is good news. As Canonical is now the primary vendor pushing AppArmor as a security solution, its vital that they take responsibility for it. And they clearly have been doing that. I look forward to seeing the inclusion of this raise their profile in next years kernel developer statistics report.

Regardless of any arguments for or against multiple security models, if its going to exist..having it in the mainline kernel is the right way for it to exist as a maintainable solution.

-jef

AppArmor set to be merged for 2.6.36

Posted Jul 30, 2010 23:09 UTC (Fri) by haradats (guest, #44782) [Link] (31 responses)

I knew AppArmor since it was formerly known as SubDomain. We have read papers on SubDomain and tried it and examined the code when we started TOMOYO project. Without those things, TOMOYO might not exist today.

When I had a presentation on TOMOYO at OLS2007, AppArmor was there and I met Seth Arnorld and other Novell developers. Four years is not short and things have been changed, Seth has left Novell, AppArmor is now included in Ubuntu and supported by Canonical, TOMOYO unexpectedly got merged in prior to AppArmor, and Ottawa Congress Centre has gone (I miss it). But Seth is still on AppArmor mailing lists and posting comments and AppArmor has been widely used in Ubuntu and has been actively developed.

Like Steve Jobs recently mentioned, "we are not perfect". "Pathname-based MAC" have not proved its advantages yet and needs much work to complement disadvantages. I'd like to welcome my great older brother sincerely and feel so happy to work with again to make our customers happy and contribute.

My photos of OLS2007
http://picasaweb.google.co.jp/haradats/OLS2007#

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 0:36 UTC (Sat) by ummmwhat (guest, #54087) [Link]

It seems that Linux will be the first system with four MAC's.

It's good that AppArmor will be included in the Linux :)

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 0:57 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (29 responses)

""Pathname-based MAC" have not proved its advantages yet and needs much work to complement disadvantages."

You are wrong! Pathname-based MAC systems are already way more useful than label-based SELinux and SMACK. It took me about 1 hour to create AppArmor profile for my application.

I tried SELinux earlier and failed miserably. So at least for me, path-based MAC systems already proved themselves.

PS: It would be nice if we could use TOMOYO with AppArmor profiles ;)

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 1:57 UTC (Sat) by haradats (guest, #44782) [Link] (28 responses)

I agree with you that usefulness (or easiness) is important in general, but it cannot be the most important issue when talking about security. (sorry, if I'm too serious)

Both label-based MAC and pathname-based MAC (if I can call them as MAC) have advantages and disadvantages. Important thing is not to choose the winner, but to cover the possible threats as much as possible. The more people use MACs, the more we can make progress.

Regarding TOMOYO, we have two versions of 2.X as mainlined and 1.X with original hooks. The reason we are developing the later is we believe we will need label and path in the future. If you are interested in running AppArmor with TOMOYO (1.X), we have been ready for years. :-)

http://tomoyo.sourceforge.jp/1.7/1st-step/ubuntu10.04-liv...

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 2:25 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (23 responses)

"I agree with you that usefulness (or easiness) is important in general, but it cannot be the most important issue when talking about security. (sorry, if I'm too serious)"

The most important thing in a security system is not its capabilities, but its ease of use. And I'm absolutely serious.

Most of security requirements of real sysadmins not complex. For example, I just want my BIND server to have access only to a few directories. I don't really worry that someone might create a hardlink to it and use it to bypass the path-based security - it can only be done if an attacker has local access, and I'm already screwed in this case. So I can gladly sacrifice some theoretical vulnerabilities for usability.

Label-based MACs do not make these kinds of security easy. SELinux can do insane things like row-level security in PostgreSQL based on a unix login user name. But I don't know any system administrator who uses SELinux.

Another example, Windows NT ACLs - they are beautiful, they can do a lot of things, they have all these wonderful inheritable permissions, negative ACEs, etc. But nobody really use them! Because it's way too hard to understand them. So Windows systems generally are less protected than Unix systems which still mostly use simplistic 40-year-old security model! In fact, on my Ubuntu system only /dev/audio and associated devices use POSIX ACLs.

PS: I meant it would be nice if AppArmor policies could be converted to TOMOYO.

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 2:55 UTC (Sat) by dlang (guest, #313) [Link] (21 responses)

as usual the truth is somewhere in between you two.

a very easy to use system that provides no security isn't worth even that small amount of effort.

on the other hand, the most secure system in the world does absolutly no good if nobody uses it.

SELinux is way out there towards the second extreme.

and before all the SELinux people jump in and say that millions of people do use it because it's default in Fedora, by use it I mean actually understanding what it does and being able to configure it.

it may provide a small amount of security in the default settings for people who just use the default setups, but the problem is that the people who are doing the things that most need security are not going to be using the defaults that the default SELinux policy is set for, and even those who do really need/want tighter security than that default provides (but a _different_ tighter setting than people who run some other set of servers, it should be tailored to the applications that that site is running)

SELinux falls on it's face in terms of being understandable to the sysadmin. On the other hand, if you have a multi-user system and really need to protect one local user from another, SELinux is the way to go.

But most of the servers running the services that most need to be secured aren't in this situation. On those servers the only local users are the administrators (and it's not unusual for the servers to be maintained via some tool so that even the sysadmins don't login to any particular box for months at a time, everything is done via a service account from a central admin tool)

In these cases, being able to easily understand the tool so that you can lock down the network accessible applications to limit what they can do will give you almost all the practical benefit of the more complex system, but since it's USED (i.e. tuned for a particular installation) while the more complex system isn't, the practical security value is much greater for the simpler version.

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 5:34 UTC (Sat) by drag (guest, #31333) [Link] (2 responses)

Pathname vs label... I don't know which is better, I don't know if I care.
What I do know is a Mac solution needs to be default deny to be truly effective. Otherwise security gains will be largely illusionary. It's a classic trap to fall into blacklists because they are easy to use.

White lists for the win.

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 5:59 UTC (Sat) by dlang (guest, #313) [Link]

I definitely agree, it's very important to whitelist things. AA does support doing so.

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 16:55 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

AA is built upon the 'whitelist' idiom. By default confined processes are forbidden to do anything, and you must grant them required permissions explicitly.

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 11:17 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (1 responses)

I think SELinux has come a long way on this aspect

I have SELinux enabled on this desktop PC despite the defaults not being suitable and despite limited time to "administrate" what is just a home PC, because there are policy booleans which cover a lot of common non-default scenarios including mine.

Specifically I have an unusual ADSL over USB setup that needs (AFAICT) PPP to load the right modules rather than it all being plug-and-play. With out-of-box SELinux on Fedora, I get a GUI alert concerning my PPP daemon, and the problem description says that if my PPP daemon should be loading modules into the running kernel then I can enable a boolean. Meanwhile, no DSL.

There's apparently a nice GUI for booleans, but I'm a shell person so I typed the necessary command into a shell. Everything has worked fine since.

Lots of scenarios can be handled with booleans. You can even switch off SELinux protection for an individual subsystem that you're having trouble with, making protection less of an "all or nothing" issue. In the Fedora world, where things get less testing, you may find (I haven't so far) you need one of these booleans because some developer screwed up. On a RHEL machine I'd guess it's most likely if there's a particular subsystem (say, the web server) that you have massively reconfigured and so its behaviour is now radically different than what was conceived for SELinux.

AppArmor set to be merged for 2.6.36

Posted Aug 13, 2010 21:03 UTC (Fri) by fredi@lwn (subscriber, #65912) [Link]

A home desktop is "easy". With easy i mean that you can configure till it meets your needs, you can reboot it if needed, hack, patch kernels/libs/apps and so on. After all it's a single machine and yours.

Now imagine you have 150+ servers to care. Different UNIX-es too although 90% Linux, but even 100% were Linux and the same distro the situations does not change much. You're not the only administrator of those machines and those provide different services, some others are virtual machines mostly hosted at a provider.

Yep, probably I'm getting OT but ... real life.
In this situation how would you manage to admin SELinux? I'm not trying to make a point, is just curiosity and wish to learn more.

For now for me, chmod and friends can let me have the job done without loosing my life caring on which function call that X machine i can allow for that Y user or such while the backlog of things to do grows on and on...

How do you people out there manage this situations? No, is not a rhetorical question, thanks in advance for the replays.

Is virtualisation a viable alternative to MAC ?

Posted Jul 31, 2010 20:31 UTC (Sat) by copsewood (subscriber, #199) [Link] (11 responses)

"On the other hand, if you have a multi-user system and really need to protect one local user from another, SELinux is the way to go."

Splitting up a physical machine with a single host OS into multiple virtual machines, even though this was designed for purposes other than MAC, seems to achieve many of the same objectives of MAC in practice. Why not give each user that needs protecting from other local users a virtual machine instead? I've been using a single VM to host multiple services, domains and websites on the same physical hosting hardware shared by many other VMs run by people I don't know for years without problems of the sort which can occur on shared login hosts. So long as the VM can't escape it's memory and disk allocation isn't this arrangement just as secure as MAC ? Is it any more likely that a bug will occur in the virtual machine monitor which violates security, than a bug will occur in a MAC system such as SELinux or AppArmour which violates security ?

Is virtualisation a viable alternative to MAC ?

Posted Jul 31, 2010 23:15 UTC (Sat) by haradats (guest, #44782) [Link] (7 responses)

The following slide by James Morris might help. In my personal opinion, virtualization is a nightmare for security.

http://namei.org/presentations/svirt-lca-2009.pdf

Is virtualisation a viable alternative to MAC ?

Posted Aug 1, 2010 0:22 UTC (Sun) by dlang (guest, #313) [Link] (2 responses)

I think that saying that virtualization is a nightmare for security is significantly overstating the problem.

I do think that the people who think that virtualization is the solution to all security problems are also drastically overstating the benefits and under estimating the risks.

Is virtualisation a viable alternative to MAC ?

Posted Aug 1, 2010 0:31 UTC (Sun) by haradats (guest, #44782) [Link]

> I do think that the people who think that virtualization is the solution to all security problems are also drastically overstating the benefits and under estimating the risks.

Agreed.

Two things were in my mind when I wrote "a nightmare". While MAC tries to build up security from the bottom (TPM, boot, system call), guest OS can directly bound to the bottom. And the internal of guest OS can hardly observed (therefore confined) from the host (or hypervisor). However, "a nightmare" was too much as you suggested.

Is virtualisation a viable alternative to MAC ?

Posted Aug 1, 2010 19:56 UTC (Sun) by drag (guest, #31333) [Link]

I believe that to properly assess the advantages of virtualization and determine how appropriate it is for a orginization it's extremely important to have the correct attitude and approach to it.

Virtualization should be mostly thought of as a cost saving mechanism and that is about it. It's a abstraction you can to use to accomplish something cheaply that otherwise would take more resources, be more difficult, or cost more.

And actually you end up sacrificing security for that lower 'TCO'.

For example:

You want to isolate network services so that if one is hacked the other will still be secure. Traditionally you would simply have to purchase multiple machines to run each service. However that is expensive and uses lots of space... so what you can do is use virtualization to isolate each service on one machine while saving money.

In that case I am sure that everybody here would agree that running multiple services on multiple physical machines is going to provide higher security then running multiple services in multiple VMs on a single machine.

So hence your trading some security for lower cost.

So it's all about proper perspective and it makes it much easier to judge the proper use of virtualization then if you get sidetracked and start thinking about security advantages. Virtualization vendors need to concentrate on promoting their products through the discussion of cost saving measures, not sort of any illusionary security advantage.

------------

Similar problems happen when people start discussing file systems, raid, and backups.

Is virtualisation a viable alternative to MAC ?

Posted Aug 1, 2010 12:15 UTC (Sun) by copsewood (subscriber, #199) [Link] (2 responses)

Yes these slides do help answer this question. Perhaps the combination of MAC at the host level and virtualisation at the user level will work better than either in isolation, because this keeps the MAC policy much simpler (hence fewer human errors) with less need for local customisation, so more manageable than when using MAC in a shared login situation ? MAC in this scenario seems to protect against bugs in the virtualisation layer.

Saying that virtualisation is less secure than a previous scenario of separate hosts for different jobs seems obvious, but if the previous scenario is single host multiple logins (e.g. for shared webhosting) then virtualisation even with just different UIDs and DAC seems to offer better security than what existed before. I think this because this direction is how the hosting of my own websites has migrated, though I would expect my upstream VM provider to be looking at and implementing the kind of DAC solution as proposed in the slides.

typo

Posted Aug 1, 2010 13:36 UTC (Sun) by copsewood (subscriber, #199) [Link] (1 responses)

"implementing the kind of DAC solution" in my previous comment should have read MAC.

typo

Posted Aug 1, 2010 20:09 UTC (Sun) by drag (guest, #31333) [Link]

Absolutely.. a properly designed MAC policy combined with virtualization should yield superior results.

But the thing to remember, especially with container-style virtualization, is that even when combined with a MAC policy mechanism losing a single VM + having a single kernel-level exploit can easily lead to the loss of your entire machine.

For a full VM solution it's a bit better as the attacker has to find a exploit in the VM software first and theoretically it is going to be more difficult then finding a local kernel exploit. But I don't know much about that.

So in this case it's still good to think of it as your losing security compared to having dedicated hosting in exchange for much lower cost.. and the provider can use MAC to recover some of the lost security. But it's still not as nice as having a separate real machine. :)

Is virtualisation a viable alternative to MAC ?

Posted Aug 2, 2010 2:34 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Reading that it wasn't clear to me how the security framework was going to help. The attack surface between the guest and the hypervisor is mostly in the form of abstracted hardware. I could see a buffer overflow or something against the virtualized hardware or tools interface but that would generally put you right in the hypervisor which would be game over man, right?

When it comes to the security of the whole system I would be far more concerned about the millions of network applications and OS exploits than buffer overflows in the handful of hypervisors which are in active use. A new exploit might be found on a common hypervisor platform, which is sufficient reason to put systems with radically different security zones on different hardware, but it probably isn't the biggest risk, probably not even in the top 10.

There is a lot more benefit to AppArmor, SELinux, TOMOYO, etc. in preventing applications with security vulnerabilities from accessing files, devices and system calls so that exploit payload isn't able to work.

Is virtualisation a viable alternative to MAC ?

Posted Aug 1, 2010 13:45 UTC (Sun) by robert_s (subscriber, #42402) [Link]

"Why not give each user that needs protecting from other local users a virtual machine instead?"

Because it's a massive waste of memory, can cause a lot of IO performance problems, and doesn't really solve the problem, just gives up on OS security and pushes the problem one step up the stack.

Is virtualisation a viable alternative to MAC ?

Posted Aug 1, 2010 21:53 UTC (Sun) by raven667 (subscriber, #5198) [Link]

Virtualization is definitely another way to approach this problem but I think having a single system image as well. Ultimately the problem that virtualization most solves is the system management problems of running many different applications on the same system. Virtualization is great but I don't think we should stop trying to solve the underlying system management problem. An OS kernel which can see the whole stack, from the hardware to the applications, is going to be able to make better scheduling decisions and be higher performance then one where everything is abstracted away, even on a modern system where most of the hardware costs of virtualization have gone away. I suppose on that tangent the outlier is disk subsystems, current RAID/SAN systems abstract IO away and miss an opportunity for the best IO scheduling decisions (can't have per-disk queues and elevators when you don't see the actual spindles).

Virtualization is a means to an end, if people could get some of the same benefits running on a single system image they will do it.

Is virtualisation a viable alternative to MAC ?

Posted Aug 6, 2010 10:43 UTC (Fri) by job (guest, #670) [Link]

I would expect it to be _much_ easier to construct a secure chroot than to make a secure VM. All that hardware to control guest kernel access to must be a nightmare to get right. Plus it is considerably easier to verify the security.

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 22:56 UTC (Sat) by jiu (guest, #57673) [Link] (3 responses)

I use neither security system on my desktop box but based on what i read here, it seems to me all that is needed to make selinux useful is a simpler front end tool to configure it. Doses this not exist?

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 23:03 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

Sure. setroubleshooter and selinux-polgengui and system-config-selinux among others.

AppArmor set to be merged for 2.6.36

Posted Aug 1, 2010 0:15 UTC (Sun) by drag (guest, #31333) [Link] (1 responses)

Sorta.

SELinux is complicated pretty much no matter what you do. You can use some of those tools to make it easy...

What we need in Linux is something like Windows XP SP2 and newer Windows versions have. We would probably call them 'Roles', but in Windows-land they are called Zones.

Each Zone has different level of privileges and NTFS Alternate Data Streams (extra metadata stored with the file in the file system) contains labels that tell the desktop what security zone that file is associated with.

Basically if you download a file using Internet Explorer it will place the file in the 'Internet Zone'. Then programs using it will worn you about it and you'll get security pop-ups and all that stuff.

We need that for the Linux desktop.

Most Desktops are going to be single user only. Even in enterprises the user will not be allowed to have admin privileges, but they will probably be the only user on that. On a desktop computer, even in enterprise desktops, the most important information is going to be contained and accessible from that user account.

Therefore the traditional restrictions that Unix imposes on user accounts is not terribly useful for protecting that user.

Any program I run, no matter how trivial, has full access to all my data and has full access to everything I do and everything I have access to.

So what is needed is a way to restrict programs I run to only having the privileges that they need, not what I need. Then we need a way to track information, such as text files that can contain shell scripts or document files that can contain macros.

A easy way to setup policies (preferably through a LSM MAC for robustness) is going to be extremely important to improving the security of the Linux desktop. If we got that it would certainly be a huge step ahead of Mac OS X and Windows in terms of desktop security.

I don't think that SELinux, the way it is now, will ever be a good match for that.

AppArmor set to be merged for 2.6.36

Posted Aug 2, 2010 2:55 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Maybe I just don't understand but aren't the situations you described some of the things that AppArmor actually does do well? The whole purpose is to add additional access control so that the application can only access the things it needs to run and not every possible thing you as a user might have access to.

AppArmor set to be merged for 2.6.36

Posted Aug 1, 2010 15:40 UTC (Sun) by SEJeff (guest, #51588) [Link]

fwiw, I introduced and use the holy crap out of POSIX ACLs on Linux servers my team manages. They are so much more flexible than standard 'nix Discretionary Access Control (user, group other, rwx, etc)

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 7:59 UTC (Sat) by jengelh (guest, #33263) [Link] (3 responses)

Both Tomoyo and AppArmor are path-based, but what are their actual important differences to warrant including two path-based LSMs?

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 13:05 UTC (Sat) by haradats (guest, #44782) [Link] (2 responses)

Your question is simple but the answer will not be as simple. First of all, determining "important" issues is not easy (imagine your friend ask you actual important differences between Linux and OpenBSD), secondary the range of features or functionalities might not be the best scale because they will grow, and fair comparison should be made by someone neutral and using both.

I once tried to make a MAC comparison chart for the newcomers and wrote the following chart.
(Some of the items need updates. Most importantly "security goals" for both AppArmor and TOMOYO are obsolete.)

http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison

My personal opinion on the major difference between AppArmor and TOMOYO are AppArmor works on selected programs ("profile") while TOMOYO treat the whole system as sets of process invocation history ("domain").

There will be a Linux security summit as a part of LinuxCon 2010 and MAC developers meet together. ;-) If possible, I will ask their opinions. (It will be great if you can join!)

https://security.wiki.kernel.org/index.php/LinuxSecurityS...

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 14:01 UTC (Sat) by jengelh (guest, #33263) [Link] (1 responses)

>There will be a Linux security summit as a part of LinuxCon 2010 and MAC developers meet together. [...] (It will be great if you can join!)

To still appear at LC-NA would require external contribution. But I am in for LC-J.

AppArmor set to be merged for 2.6.36

Posted Jul 31, 2010 22:44 UTC (Sat) by haradats (guest, #44782) [Link]

Though upcoming LC2010 will be a great opportunity, no critical decisions shall be made by just one meeting and its attendees. Proposing a new LSM module and security issues are discussed via LSM mailing list which is opened to everybody. You can browse the archive and join the conversation regardless of your physical location.

http://vger.kernel.org/vger-lists.html#linux-security-module

The merging process is not easy. It took two years for TOMOYO and four years for AppArmor since their first *postings*, which means they have been rejected for those periods.

http://www.slideshare.net/haradats/time-to-glean-mac-for-...

Merging cannot happen by mistakes, so why don't we celebrate AppArmor's new start for the momemnt? :-)


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds