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>
Posted Jul 30, 2010 19:57 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link]
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
Posted Jul 30, 2010 23:09 UTC (Fri)
by haradats (guest, #44782)
[Link] (31 responses)
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
Posted Jul 31, 2010 0:36 UTC (Sat)
by ummmwhat (guest, #54087)
[Link]
It's good that AppArmor will be included in the Linux :)
Posted Jul 31, 2010 0:57 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (29 responses)
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 ;)
Posted Jul 31, 2010 1:57 UTC (Sat)
by haradats (guest, #44782)
[Link] (28 responses)
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...
Posted Jul 31, 2010 2:25 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (23 responses)
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.
Posted Jul 31, 2010 2:55 UTC (Sat)
by dlang (guest, #313)
[Link] (21 responses)
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.
Posted Jul 31, 2010 5:34 UTC (Sat)
by drag (guest, #31333)
[Link] (2 responses)
White lists for the win.
Posted Jul 31, 2010 5:59 UTC (Sat)
by dlang (guest, #313)
[Link]
Posted Jul 31, 2010 16:55 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jul 31, 2010 11:17 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
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.
Posted Aug 13, 2010 21:03 UTC (Fri)
by fredi@lwn (subscriber, #65912)
[Link]
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.
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.
Posted Jul 31, 2010 20:31 UTC (Sat)
by copsewood (subscriber, #199)
[Link] (11 responses)
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 ?
Posted Jul 31, 2010 23:15 UTC (Sat)
by haradats (guest, #44782)
[Link] (7 responses)
Posted Aug 1, 2010 0:22 UTC (Sun)
by dlang (guest, #313)
[Link] (2 responses)
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.
Posted Aug 1, 2010 0:31 UTC (Sun)
by haradats (guest, #44782)
[Link]
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.
Posted Aug 1, 2010 19:56 UTC (Sun)
by drag (guest, #31333)
[Link]
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.
Posted Aug 1, 2010 12:15 UTC (Sun)
by copsewood (subscriber, #199)
[Link] (2 responses)
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.
Posted Aug 1, 2010 13:36 UTC (Sun)
by copsewood (subscriber, #199)
[Link] (1 responses)
Posted Aug 1, 2010 20:09 UTC (Sun)
by drag (guest, #31333)
[Link]
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. :)
Posted Aug 2, 2010 2:34 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
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.
Posted Aug 1, 2010 13:45 UTC (Sun)
by robert_s (subscriber, #42402)
[Link]
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.
Posted Aug 1, 2010 21:53 UTC (Sun)
by raven667 (subscriber, #5198)
[Link]
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.
Posted Aug 6, 2010 10:43 UTC (Fri)
by job (guest, #670)
[Link]
Posted Jul 31, 2010 22:56 UTC (Sat)
by jiu (guest, #57673)
[Link] (3 responses)
Posted Jul 31, 2010 23:03 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Aug 1, 2010 0:15 UTC (Sun)
by drag (guest, #31333)
[Link] (1 responses)
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.
Posted Aug 2, 2010 2:55 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
Posted Aug 1, 2010 15:40 UTC (Sun)
by SEJeff (guest, #51588)
[Link]
Posted Jul 31, 2010 7:59 UTC (Sat)
by jengelh (guest, #33263)
[Link] (3 responses)
Posted Jul 31, 2010 13:05 UTC (Sat)
by haradats (guest, #44782)
[Link] (2 responses)
I once tried to make a MAC comparison chart for the newcomers and wrote the following chart.
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...
Posted Jul 31, 2010 14:01 UTC (Sat)
by jengelh (guest, #33263)
[Link] (1 responses)
To still appear at LC-NA would require external contribution. But I am in for LC-J.
Posted Jul 31, 2010 22:44 UTC (Sat)
by haradats (guest, #44782)
[Link]
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? :-)
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
http://picasaweb.google.co.jp/haradats/OLS2007#
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
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.
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
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.
Is virtualisation a viable alternative to MAC ?
Is virtualisation a viable alternative to MAC ?
Is virtualisation a viable alternative to MAC ?
Is virtualisation a viable alternative to MAC ?
Is virtualisation a viable alternative to MAC ?
Is virtualisation a viable alternative to MAC ?
typo
typo
Is virtualisation a viable alternative to MAC ?
Is virtualisation a viable alternative to MAC ?
Is virtualisation a viable alternative to MAC ?
Is virtualisation a viable alternative to MAC ?
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36
(Some of the items need updates. Most importantly "security goals" for both AppArmor and TOMOYO are obsolete.)
AppArmor set to be merged for 2.6.36
AppArmor set to be merged for 2.6.36