![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1){kind=small}
We just closed the doors on the 2011 Linux Security Summit a few hours ago and I wanted to jot down a few notes while everything was still fresh in my mind. Once again, a big thanks to all of our presenters, James Morris and the rest of the organizing committee; my personal opinion is that the summit was a success this year and I look forward to doing this again in 2012.
Just as in the past, presentations will be posted at the wiki below once kernel.org comes back online.
http://security.wiki.kernel.org/index.ph
Smack is Alive and Well, Casey Schaufler
This presentation started with a brief introduction to Smack and then moved on to presenting the recent users, motivations and focus. While Smack has been incorporated into at least one general purpose Linux Distribution, Ubuntu, over the past year or two Smack has grown increasingly focused on small and embedded devices. Functionality wise, Smack has gained several new additions including process labels and transmutable directories. Process labels allow an executable file to be started with a label specified in the file's xattrs and not the parent process's attributes. Transmutable directories allow two differently labeled processes to write into each other's directories without requiring full write access to the other label; this should make it much easier to share files and data between labels. Beyond the new functionality, performance improvements, increased Linux Test Project coverage and improved consistency between AF_UNIX and AF_INET sockets have seen their way, or will soon see their way into Smack.
MeeGo platform security, including Smack userspace: http://meego.gitorious.org/meego-platfor
The Case for SE Android, Stephen Smalley
This presentation discussed a recent effort to prototype a SELinux implementation for Android. While SELinux is well known in desktop and server Linux environments, it is still rare in mobile and embedded systems due to concerns around resource usage and differences in both the kernels and userspace. This talk explained the basic Linux/Android differences and what was needed to enable SELinux on the Android platform. Resource issues around policy size were addressed through a greatly simplified SELinux policy which avoided per-application policy and relied on a relatively simple rule set. Finally, the effectiveness of the prototype was evaluated by examining a recent Android vulnerability with a known exploit and determining the effectiveness of the SELinux Android port in preventing the exploit. In the end, this remains a prototype at present, designed to investigate Android's security capabilities, but it shows quite a bit of promise and has a lot to offer beyond the current Android security functionality.
Overview of the Linux Integrity Architecture, David Safford and Mimi Zohar
The Linux Integrity Architecture project has seen a lot of activity over the past few years and the presentation started off with an overview of project, including a status update on where each piece of functionality stood with respect to upstream and established distributions. The good news is that almost all of the IMA project is either currently upstream or patches have been submitted and are being discussed on the related mailing lists. One of the presentation highlights was a demo tying together the IMA principals and virtualization to demonstrate a "Trusted Cloud". While there is work to be done, the IMA project has made great strides and already offers some impressive functionality.
IMA project website: http://linux-ima.sf.net
Digital Signature Support for IMA/EVM, Dmitry Kasatkin and Casey Schaufler
This presentation addressed a problem common to system and device manufacturers who install a single "golden image" on each system they ship: how do you reconcile the business need of a single install image with a TPM based EVM HMAC which uses a per-device key stored in the TPM? One potential answer is to expand on the EVM mechanism to support public key digital signatures in addition to the TPM based HMAC. When the devices are initially installed, a public key certificate is installed into the Linux Kernel keyring via an initrd with the filesystem using digital signatures for the EVM xattr in place of the traditional HMAC. As the files are accessed, the EVM digital signature is verified, and if correct, it is replaced by a TPM generated HMAC. If the EVM digital signature verification fails, access is denied in the same way as if the EVM HMAC verification had failed.
Protecting the Filesystem Integrity of a Fedora 15 Virtual Machine from Offline Attacks using IMA/EVM, Peter Kruus
This presentation covered some work being done to better secure Fedora 15 guests running on VMWare ESXi while the guests were both running and offline. All systems are vulnerable to offline attacks, but in the case of virtual systems, offline vulnerabilities can sometimes be much easier to exploit due to the availability of the host system and guest storage volumes. In order to help mitigate this problem, the presenter leveraged the existing IMA/EVM support in Fedora 15 to verify the integrity of critical system files, but unfortunately due to missing vTPM support in VMWare ESXi the presenter was unable to leverage TPM based HMACs in the EVM attributes. The solution was to use a passphrase protected key which was loaded at boot through a combination of the system's initrd and dracut. While this solution does provide an increased level of protection against attack, for this approach to be truly successful, full vTPM support is needed in the hypervisor to allow the guest to utilize the TPM. While vTPM patches have been submitted for QEMU/KVM, the state of the vTPM in VMWare ESXi is unknown.
Integrity-checked Block Devices with Device Mapper, Will Drewry and Mandeep Baines
This presentation dealt with an enhancement to the Linux Kernel Device Mapper to perform block level integrity verification. This solution was designed primarily for the Linux based Chromium OS running on modest netbook class hardware where boot performance was a significant requirement. Helping to simplify the solution was the fact that the system is very well defined and operates in a read-only mode such that the integrity verification mechanism does not need to worry about online updates to the storage volume. The solution, dm-verity, uses a slightly modified hash tree, with the root hash specified on the kernel command line to quickly verify the integrity of the entire block device. Optimization is ongoing, but already the developers are able to boot a ~800MB Chromium OS root partition in ~1.2s on an Atom CPU using a SSD storage volume. While this integrity verification solution may not lend itself quite as well to general purpose systems as the TPM/IMA based solutions, it presents a novel solution that helps solve Chromium OS's needs in a a high performance, low cost manner.
Kernel Hardening Roundtable, Kees Cook and Will Drewry
This roundtable started with a discussion on the different kernel interfaces where the kernel is exposed to user input, malicious or otherwise. From here the focus shifted to how the existing security mechanisms, such as DAC, LSM and capabilities, impact the kernel's exposed interfaces - for better or worse. At this point it was clear, if it wasn't already, that the Linux Kernel remains far too exposed to malicious users/applications and some additional hardening techniques are needed.
While many hardening ideas were discussed, the two main points of discussion revolved around system call filtering/reduction and the hardening techniques found in grsecurity. With respect to system call filtering, work has been ongoing this year to expand the mainline seccomp functionality to be more flexible and useful for a wider range of applications. Plenty of discussion has already occurred on the mailing lists and more is expected as the enhanced seccomp developer has promised a new round of patches soon. Similarly, work has recently been ongoing to decompose the rejected grsecurity patch and repackage it in a series of patches which will hopefully be acceptable to the upstream kernel maintainers.
Sandbox powered by the current mainline seccomp: http://code.google.com/p/seccompsandbox
Ubuntu Linux Kernel hardening tasks: http://wiki.ubuntu.com/SecurityTeam/Road
Linux Kernel hardening mailing lists: http://www.openwall.com/lists (see the kernel-hardening list)
LSM Architecture Roundtable, Kees Cook and Casey Schaufler
This roundtable dealt primarily with the issues related to multiple LSMs, from APIs and determining which LSM was enabled in the kernel to architectural issues blocking multiple concurrent LSMs. With respect to determining the active LSM and LSM APIs, the discussion was largely a group brainstorming session with developers discussing the pros and cons of various solutions; while most agreed the a general LSM userspace API was more problem than it was worth, there was some general agreement on LSM conventions that should help unify some of the most basic LSM API functionality in the future.
This discussion around running multiple concurrent LSMs was much more focused, with patches being proposed as recently as February, although everyone did agree that the patches had serious limitations due to shortcomings with the LSM hooks/blobs in the kernel. In the end, several inherent blockers to concurrent LSM operation remained, but the "religious" arguments against the idea seemed to be less than in past years.
Just as in the past, presentations will be posted at the wiki below once kernel.org comes back online.
http://security.wiki.kernel.org/index.ph
Smack is Alive and Well, Casey Schaufler
This presentation started with a brief introduction to Smack and then moved on to presenting the recent users, motivations and focus. While Smack has been incorporated into at least one general purpose Linux Distribution, Ubuntu, over the past year or two Smack has grown increasingly focused on small and embedded devices. Functionality wise, Smack has gained several new additions including process labels and transmutable directories. Process labels allow an executable file to be started with a label specified in the file's xattrs and not the parent process's attributes. Transmutable directories allow two differently labeled processes to write into each other's directories without requiring full write access to the other label; this should make it much easier to share files and data between labels. Beyond the new functionality, performance improvements, increased Linux Test Project coverage and improved consistency between AF_UNIX and AF_INET sockets have seen their way, or will soon see their way into Smack.
MeeGo platform security, including Smack userspace: http://meego.gitorious.org/meego-platfor
The Case for SE Android, Stephen Smalley
This presentation discussed a recent effort to prototype a SELinux implementation for Android. While SELinux is well known in desktop and server Linux environments, it is still rare in mobile and embedded systems due to concerns around resource usage and differences in both the kernels and userspace. This talk explained the basic Linux/Android differences and what was needed to enable SELinux on the Android platform. Resource issues around policy size were addressed through a greatly simplified SELinux policy which avoided per-application policy and relied on a relatively simple rule set. Finally, the effectiveness of the prototype was evaluated by examining a recent Android vulnerability with a known exploit and determining the effectiveness of the SELinux Android port in preventing the exploit. In the end, this remains a prototype at present, designed to investigate Android's security capabilities, but it shows quite a bit of promise and has a lot to offer beyond the current Android security functionality.
Overview of the Linux Integrity Architecture, David Safford and Mimi Zohar
The Linux Integrity Architecture project has seen a lot of activity over the past few years and the presentation started off with an overview of project, including a status update on where each piece of functionality stood with respect to upstream and established distributions. The good news is that almost all of the IMA project is either currently upstream or patches have been submitted and are being discussed on the related mailing lists. One of the presentation highlights was a demo tying together the IMA principals and virtualization to demonstrate a "Trusted Cloud". While there is work to be done, the IMA project has made great strides and already offers some impressive functionality.
IMA project website: http://linux-ima.sf.net
Digital Signature Support for IMA/EVM, Dmitry Kasatkin and Casey Schaufler
This presentation addressed a problem common to system and device manufacturers who install a single "golden image" on each system they ship: how do you reconcile the business need of a single install image with a TPM based EVM HMAC which uses a per-device key stored in the TPM? One potential answer is to expand on the EVM mechanism to support public key digital signatures in addition to the TPM based HMAC. When the devices are initially installed, a public key certificate is installed into the Linux Kernel keyring via an initrd with the filesystem using digital signatures for the EVM xattr in place of the traditional HMAC. As the files are accessed, the EVM digital signature is verified, and if correct, it is replaced by a TPM generated HMAC. If the EVM digital signature verification fails, access is denied in the same way as if the EVM HMAC verification had failed.
Protecting the Filesystem Integrity of a Fedora 15 Virtual Machine from Offline Attacks using IMA/EVM, Peter Kruus
This presentation covered some work being done to better secure Fedora 15 guests running on VMWare ESXi while the guests were both running and offline. All systems are vulnerable to offline attacks, but in the case of virtual systems, offline vulnerabilities can sometimes be much easier to exploit due to the availability of the host system and guest storage volumes. In order to help mitigate this problem, the presenter leveraged the existing IMA/EVM support in Fedora 15 to verify the integrity of critical system files, but unfortunately due to missing vTPM support in VMWare ESXi the presenter was unable to leverage TPM based HMACs in the EVM attributes. The solution was to use a passphrase protected key which was loaded at boot through a combination of the system's initrd and dracut. While this solution does provide an increased level of protection against attack, for this approach to be truly successful, full vTPM support is needed in the hypervisor to allow the guest to utilize the TPM. While vTPM patches have been submitted for QEMU/KVM, the state of the vTPM in VMWare ESXi is unknown.
Integrity-checked Block Devices with Device Mapper, Will Drewry and Mandeep Baines
This presentation dealt with an enhancement to the Linux Kernel Device Mapper to perform block level integrity verification. This solution was designed primarily for the Linux based Chromium OS running on modest netbook class hardware where boot performance was a significant requirement. Helping to simplify the solution was the fact that the system is very well defined and operates in a read-only mode such that the integrity verification mechanism does not need to worry about online updates to the storage volume. The solution, dm-verity, uses a slightly modified hash tree, with the root hash specified on the kernel command line to quickly verify the integrity of the entire block device. Optimization is ongoing, but already the developers are able to boot a ~800MB Chromium OS root partition in ~1.2s on an Atom CPU using a SSD storage volume. While this integrity verification solution may not lend itself quite as well to general purpose systems as the TPM/IMA based solutions, it presents a novel solution that helps solve Chromium OS's needs in a a high performance, low cost manner.
Kernel Hardening Roundtable, Kees Cook and Will Drewry
This roundtable started with a discussion on the different kernel interfaces where the kernel is exposed to user input, malicious or otherwise. From here the focus shifted to how the existing security mechanisms, such as DAC, LSM and capabilities, impact the kernel's exposed interfaces - for better or worse. At this point it was clear, if it wasn't already, that the Linux Kernel remains far too exposed to malicious users/applications and some additional hardening techniques are needed.
While many hardening ideas were discussed, the two main points of discussion revolved around system call filtering/reduction and the hardening techniques found in grsecurity. With respect to system call filtering, work has been ongoing this year to expand the mainline seccomp functionality to be more flexible and useful for a wider range of applications. Plenty of discussion has already occurred on the mailing lists and more is expected as the enhanced seccomp developer has promised a new round of patches soon. Similarly, work has recently been ongoing to decompose the rejected grsecurity patch and repackage it in a series of patches which will hopefully be acceptable to the upstream kernel maintainers.
Sandbox powered by the current mainline seccomp: http://code.google.com/p/seccompsandbox
Ubuntu Linux Kernel hardening tasks: http://wiki.ubuntu.com/SecurityTeam/Road
Linux Kernel hardening mailing lists: http://www.openwall.com/lists (see the kernel-hardening list)
LSM Architecture Roundtable, Kees Cook and Casey Schaufler
This roundtable dealt primarily with the issues related to multiple LSMs, from APIs and determining which LSM was enabled in the kernel to architectural issues blocking multiple concurrent LSMs. With respect to determining the active LSM and LSM APIs, the discussion was largely a group brainstorming session with developers discussing the pros and cons of various solutions; while most agreed the a general LSM userspace API was more problem than it was worth, there was some general agreement on LSM conventions that should help unify some of the most basic LSM API functionality in the future.
This discussion around running multiple concurrent LSMs was much more focused, with patches being proposed as recently as February, although everyone did agree that the patches had serious limitations due to shortcomings with the LSM hooks/blobs in the kernel. In the end, several inherent blockers to concurrent LSM operation remained, but the "religious" arguments against the idea seemed to be less than in past years.
To add to the recent email updates, I thought I would mention that I'm now on twitter too at @paul_via_tweet. Not much there right now, but since all the "cool kids" are on the twitter these days, how could I resist?
Hello again, last week I made a quick post to say that my @hp.com email address was going away; the reason for that, as many had guessed, was that I was leaving HP for a new employer. As of this past Monday, August 8th, 2011, I'm happy to say that I am now working for Red Hat. This should be good news for anyone interested in the Linux labeled networking bits and the assorted LSM network access controls as my new employer should allow me to spend more time maintaining and working on these things than I have over the past few years.
So, with a new job comes a new email address; you can continue to send me email at paul@paul-moore.com, but now you can also reach me at pmoore@redhat.com.
So, with a new job comes a new email address; you can continue to send me email at paul@paul-moore.com, but now you can also reach me at pmoore@redhat.com.
Just a quick update to let everyone know that my @hp.com email address is going to stop working on Friday, August 5, 2011. If you need to get in touch with me please send me email at paul@paul-moore.com.
If you've ever configured a tagged VLAN on a Linux system you know that for each VLAN ID on the system there exists a matching network interface, this is a nice feature that helps ease the pain of managing multiple VLANs but it presents an interesting question for SELinux administrators: how do the interface level access controls work? Since the individual VLAN interfaces are "layered" on top of the underlying physical interface, do the SELinux access controls happen at the physical interface, the VLAN interfaces or both?
It turns out the answer is quite simple and applies regardless of how many layers of network interfaces you have configured; the SELinux interface level network access controls are applied to traffic as it pass through the top most interface layer. In the case of a system configured with multiple tagged VLANs, the access controls are applied at the VLAN interface layer. In the case of a system configured with multiple tagged VLANs running on top of a bonded interface running on top of a pair of physical interfaces, the access controls are applied at the VLAN interface layer. Regardless of the number of interface layers, the SELinux access controls are always applied to the top most interface layer.
Further, assigning SELinux security labels to these pseudo-interfaces is done the same way you would for a regular physical interface: using the semanage tool. Once you have the interfaces labeled, you can start defining your network access control policy just as if you were working with a physical interfaces.
It turns out the answer is quite simple and applies regardless of how many layers of network interfaces you have configured; the SELinux interface level network access controls are applied to traffic as it pass through the top most interface layer. In the case of a system configured with multiple tagged VLANs, the access controls are applied at the VLAN interface layer. In the case of a system configured with multiple tagged VLANs running on top of a bonded interface running on top of a pair of physical interfaces, the access controls are applied at the VLAN interface layer. Regardless of the number of interface layers, the SELinux access controls are always applied to the top most interface layer.
Further, assigning SELinux security labels to these pseudo-interfaces is done the same way you would for a regular physical interface: using the semanage tool. Once you have the interfaces labeled, you can start defining your network access control policy just as if you were working with a physical interfaces.
There have been quite a few questions lately about how to enable the SELinux network ingress/egress controls on recent Fedora releases. This is good because it means people actually want to use this stuff, but it is also bad because it tells me that I haven't done a very good job explaining how to use them. Actually, looking back on this site I see that while I've written about the ingress/egress controls I haven't described how you would enable them on a modern Linux distribution. Ooops.
However, fear not faithful readers and confused administrators, for this is post shall explain, in four easy steps, how to enable the SELinux network ingress/egress controls. Without further ado, let's begin ...
The first step is to ensure you have the netlabel_tools package installed. This is necessary because the netlabel_tools package contains the netlabelctl application which we will be using to configure NetLabel in the final step. Using yum you should be able to install netlabel_tools with the following command:
After you have installed the netlabel_tools package the next step is to ensure you have a SELinux policy module loaded which defines at least two new types: one to be assigned to a network interface and another to be assigned to network traffic. To be honest, you'll probably want to create more than just those two types but that will be dependent on your particular configuration; for more information I suggest you look at my original post on the ingress/egress controls where I go into more detail on the policy aspect of these controls. Regardless of what you decide, for the example here I will be using "foo_netif_t" for the network interface type and "foo_peer_t" for the network traffic type.
With the SELinux policy module loaded and our new types defined, it is time to assign our new network interface type to an interface on the system. We use the semanage tool to manipulate the SELinux types assigned to network interfaces, in order to add a type to an interface, "eth2" in this example, we use the following command:
We can verify that the interface is assigned the correct type with the following command:
Now that we have the network interface labeled the final step is to setup some form of peer labeling on the network. For many of you not using CIPSO or labeled IPsec, this means configuring NetLabel's static/fallback labels. In this example, we are going to configure all of the IPv4 and IPv6 traffic entering the system via "eth2" as having the "foo_peer_t" label; we do this with the following command:
We can verify the configuration with the following command:
At this point the SELinux network ingress/egress control should be up and running on your system. As a reminder, you'll want to be sure to have all the right allow rules for these new controls in your SELinux policy as simply adding the types without the allow rules could result in a total loss of network access; because of this I recommend you do this with SELinux in permissive mode until you are comfortable with how the system operates.
Good luck, and as usual, if you have any problems or questions feel free to leave a comment below.
However, fear not faithful readers and confused administrators, for this is post shall explain, in four easy steps, how to enable the SELinux network ingress/egress controls. Without further ado, let's begin ...
The first step is to ensure you have the netlabel_tools package installed. This is necessary because the netlabel_tools package contains the netlabelctl application which we will be using to configure NetLabel in the final step. Using yum you should be able to install netlabel_tools with the following command:
# yum install netlabel_tools
After you have installed the netlabel_tools package the next step is to ensure you have a SELinux policy module loaded which defines at least two new types: one to be assigned to a network interface and another to be assigned to network traffic. To be honest, you'll probably want to create more than just those two types but that will be dependent on your particular configuration; for more information I suggest you look at my original post on the ingress/egress controls where I go into more detail on the policy aspect of these controls. Regardless of what you decide, for the example here I will be using "foo_netif_t" for the network interface type and "foo_peer_t" for the network traffic type.
With the SELinux policy module loaded and our new types defined, it is time to assign our new network interface type to an interface on the system. We use the semanage tool to manipulate the SELinux types assigned to network interfaces, in order to add a type to an interface, "eth2" in this example, we use the following command:
# semanage interface -a -t foo_netif_t eth2
We can verify that the interface is assigned the correct type with the following command:
# semanage interface -l SELinux Interface Context eth2 system_u:object_r:foo_netif_t:s0
Now that we have the network interface labeled the final step is to setup some form of peer labeling on the network. For many of you not using CIPSO or labeled IPsec, this means configuring NetLabel's static/fallback labels. In this example, we are going to configure all of the IPv4 and IPv6 traffic entering the system via "eth2" as having the "foo_peer_t" label; we do this with the following command:
# netlabelctl unlbl add interface:eth2 address:0.0.0.0/0 label:system_u:object_r:foo_peer_t:s0 # netlabelctl unlbl add interface:eth2 address:::/0 label:system_u:object_r:foo_peer_t:s0
We can verify the configuration with the following command:
# netlabelctl -p unlbl list
Accept unlabeled packets : on
Configured NetLabel address mappings (2)
interface: eth2
address: 0.0.0.0/0
label: "system_u:object_r:foo_peer_t:s0"
address: ::/0
label: "system_u:object_r:foo_peer_t:s0"
At this point the SELinux network ingress/egress control should be up and running on your system. As a reminder, you'll want to be sure to have all the right allow rules for these new controls in your SELinux policy as simply adding the types without the allow rules could result in a total loss of network access; because of this I recommend you do this with SELinux in permissive mode until you are comfortable with how the system operates.
Good luck, and as usual, if you have any problems or questions feel free to leave a comment below.
I'm more than a little late posting this, but below you'll find a copy of the NetLabel presentation I gave at this past year's LinuxCon. Sure, it is old news, but if you ever wanted to know what NetLabel does and why it exists in the first place this is still good stuff.
Presentation download: NetLabel: What, Why & Where
Presentation download: NetLabel: What, Why & Where
In a few weeks I'll be giving a presentation and tutorial on NetLabel at LinuxCon. Both as a speaker and as a member of the audience I've always felt that the best presentations/tutorials are the ones that cover what the audience is really interested in hearing. The only problem is that in most cases the presentation material needs to be generated before the presenter ever meets the audience. With that in mind, I'd like to reach out to all of you reading this entry and ask two simple questions:
* What would you like to see in a NetLabel presentation?
* What would you like to learn in a NetLabel tutorial?
Don't be shy now ;)
* What would you like to see in a NetLabel presentation?
* What would you like to learn in a NetLabel tutorial?
Don't be shy now ;)
The labeled networking changes in 2.6.30 are fairly significant but not because of new features or functionality. The changes to 2.6.30 are largely fixes for bugs discussed previously as well as some minor improvements to Smack's internal labeled networking code. From a labeled networking user's point of view 2.6.30 doesn't do anything new, but it does everything it already does much better.
It is also worth noting that the TCP labeled networking bug fixes in 2.6.30 have been included in the 2.6.29.4 stable kernel release. I strongly encourage all of you running 2.6.28 or 2.6.29 kernels who aren't comfortable jumping to the 2.6.30 kernel to move your system to a 2.6.29.4 kernel as soon as possible.
UPDATE: I forgot to mention that the older "compat_net" network access controls have finally been removed in the 2.6.30 release. For those of you who may still be relying on the "compat_net" behavior, I've written a short guide on how to transition to the new Secmark based controls. If you run into any problems go ahead and drop a note in the comments.
It is also worth noting that the TCP labeled networking bug fixes in 2.6.30 have been included in the 2.6.29.4 stable kernel release. I strongly encourage all of you running 2.6.28 or 2.6.29 kernels who aren't comfortable jumping to the 2.6.30 kernel to move your system to a 2.6.29.4 kernel as soon as possible.
UPDATE: I forgot to mention that the older "compat_net" network access controls have finally been removed in the 2.6.30 release. For those of you who may still be relying on the "compat_net" behavior, I've written a short guide on how to transition to the new Secmark based controls. If you run into any problems go ahead and drop a note in the comments.
The week of September 20th is going to be a busy one with both LinuxCon and the Linux Plumbers Conference co-located in Portland, Oregon. However, having both conferences in the same place on the same week should make it much easier for people to justify the travel. If you are planning on attending one or both of the conferences you should know that each conference has a dedicated security track or mini-summit which you probably want to attend (and submit a proposal too!).
On the day before LinuxCon starts, we will be holding this year's SELinux Developer's Summit. The SELinux Developer Summit is always a great opportunity to meet several of the SELinux developer's in person and discuss anything and everything SELinux. To get a better idea of what to expect you can check out the main page and talks from last year. For those of you interested in presenting a topic this year, the Call for Proposals is open until July 1st, so get your abstract in soon.
During the Linux Plumbers Conference there will be a dedicated security track for anything related to Linux security. The security track is new this year and promises to have some interesting talks, if you would like to add to that list James Morris put together a nice post with all the information you need; just beware the deadline for new proposals is June 15th.
On the day before LinuxCon starts, we will be holding this year's SELinux Developer's Summit. The SELinux Developer Summit is always a great opportunity to meet several of the SELinux developer's in person and discuss anything and everything SELinux. To get a better idea of what to expect you can check out the main page and talks from last year. For those of you interested in presenting a topic this year, the Call for Proposals is open until July 1st, so get your abstract in soon.
During the Linux Plumbers Conference there will be a dedicated security track for anything related to Linux security. The security track is new this year and promises to have some interesting talks, if you would like to add to that list James Morris put together a nice post with all the information you need; just beware the deadline for new proposals is June 15th.
