• Presentation
• Register
• Program
• Organizing Comittee
• Listing of registered people
• Translators team

riel	ok, I guess it's time to start this afternoon's talk
riel	I have set the channel to moderated, so only ops can talk now
riel	if you have questions or want to chat about the presentation, you can do so in #qc
riel	I think there will also be a spanish translation in #redes
riel	for the people who prefer the talk in spanish
riel	this afternoon, my friend and colleague James Morris will talk about the interesting (but rather complex) subject of SELinux networking
riel	there are a lot of aspects involved with this, so I won't confuse you by talking about a wrong one in my introduction ;)
riel	James Morris has been a linux kernel developer for quite a while
riel	he is a member of the netfilter core team
riel	and is now paid by Red Hat to work on selinux things
riel	I hope this talk will touch on both sides of James his Linux experience
riel	now I'll sit back to enjoy the talk
jamesm	Welcome everyone :-)
jamesm	This talk will be about networking under SELinux, but first I will provide a brief introduction to SELinux itself.
jamesm	It provides Linux with Mandatory Access Control (MAC) security.
jamesm	SELinux will be part of the 2.6 kernel.
jamesm	Standard Unix/Linux has Discretionary Access Control (DAC), where
jamesm	most security decisions are made at the user's discretion.
jamesm	For example,
jamesm	if a user wants to share a file, they can just type chmod 644 file to
jamesm	make it readable by others.
jamesm	Under a MAC system, the kernel will actually decide whether the file
jamesm	can be shared, instead of the user.
jamesm	A security policy will be used
jamesm	to specify the security rules for the system.
jamesm	SELinux uses a generalized security model, where kernel objects
jamesm	(e.g. processes, files) are each labeled with a security context.
jamesm	A security context can contain a number of security attributes for
jamesm	the object.
jamesm	e.g. the role is an attribute, and could be sysadmin
jamesm	When a security decision has to be made, SELinux
jamesm	looks at the security contexts of each object and then consults
jamesm	the security policy to determine whether access is granted.
jamesm	For
jamesm	example, only a process labeled with a sysadmin role might be
jamesm	allowed to access the /etc/shadow.
jamesm	Hopefully this has introduced two important ideas in SELinux:  Mandatory Access Control, and Security Contexts
jamesm	This is a very simplified overview.  More information on SELinux can
jamesm	be found at http://www.nsa.gov/selinux/docs.html
jamesm	Also, a really good introductory article is at
jamesm	http://sourceforge.net/docman/display_doc.php?docid=15285&group_id=21266
jamesm	by Faye Coker.
jamesm	SELinux extends MAC security to networking.
jamesm	This is important and useful because of the number of systems that are now networked.
jamesm	SELinux allows networked machines to be hardened against many types of vulnerabilities and user errors.
jamesm	Firstly, all socket system calls are covered by SELinux.
jamesm	e.g. a process
jamesm	must have permission to use socket(), bind(), listen(), accept(),
jamesm	sendmsg(), recvmsg() etc.
jamesm	This effectively allows SELinux to control
jamesm	which applications can do networking.
jamesm	If you can't use the socket system calls, you will have problems doing any networking.
jamesm	Some of these permissions are further broken down by protocol: TCP, UDP
jamesm	and Raw IP.
jamesm	So, for example, SELinux is able to
jamesm	impose a policy where a certain application, such as Apache, can only
jamesm	perform socket calls for TCP.
jamesm	If Apache was compromised, the kernel
jamesm	would not allow Apache to work with UDP sockets.
jamesm	Further permissions are provided for bind(), where the port number
jamesm	can be specified (e.g. only listen on port 80), as well as which local
jamesm	IP addresses may be used.
jamesm	(note that no changes need to be made to applications for this, it is all controlled via security policy and enforced at the kernel level)
jamesm	Permissions are also provided which allow policy to specify which
jamesm	network interfaces traffic can be sent or received over.
jamesm	his is
jamesm	also applied on a per protocol basis.
jamesm	For example, you may write
jamesm	a policy which says that Apache can only send and and receive TCP
jamesm	traffic over eth1.
jamesm	Network traffic can also be controlled by IP address for a given
jamesm	process and protocol.
jamesm	Combining these controls together provides a powerful and flexible
jamesm	way to contain network facing applications.
jamesm	Putting it all together, a simple example would be to specify
jamesm	that sshd is allowed to use the socket system calls for TCP,
jamesm	bind to port 22, send and receive TCP traffic over an internal
jamesm	interface to intranet addresses only.
jamesm	Applications such as ssh, sshd, bind etc. can all be locked down in a similar way.
jamesm	One question that you might be asking is how is this different to iptables?
jamesm	Firstly, the network traffic is associated with specific processes (this can only be done in a very limited way under iptables as it is only present at the network layer)
jamesm	The SELinux controls are part of a much larger scheme where the applications are also constrained from what they can do e.g. on the local filesytem.
jamesm	Nurbs asks:  can one filter based on SE roles and such with netfilter/iptables (in addition to what is given by the SE linux configuration already)?
jamesm	yes, you could write an iptables match for the security context, but it would only work for outgoing packets generated locally
jamesm	for incoming packets, the iptables hook at the network layer cannot know how the packet is eventually associated with userspace (if at all)
jamesm	riel asks: are there plans to transport the security context across the network (with ipsec), so you can filter incoming packets based on security context too ?
jamesm	yes, I will cover that soon
jamesm	What we have with SELinux networking currently is a way to harden systems against attacks (internal as well as external), and configuration errors, integrated with a comprehensive MAC system.
jamesm	Many (if not most) of the vulnerabilities seen recently would have been contained by SELinux, although it cannot protect against kernel bugs (e.g. the do_brk() vulnerability) or poorly implemented policy.
jamesm	So it is not a magic bullet.
jamesm	SELinux is still under development (work on features is expected
jamesm	to continue after the 2.6.0 kernel is released)
jamesm	aalih asks:  what's the overhead associated with all the SE's check?
jamesm	so far, from my own measurements, between 5-15% depending on what you are testing
jamesm	as more networking features are implemented, networking will get slower
jamesm	however, some major work on performance and scalability improvments will take place within the next 6 months
jamesm	for example, there is one lock which seems to account for half of the performance hit: that is something which should be fixable
jamesm	but there will always be some overhead
jamesm	hanna asks: what lock is that?
jamesm	it is the avc_lock in avc_has_perm(), which is taken for every single access permission check
jamesm	this looks like a candidate for RCU (read copy update)
jamesm	feistel asks: differences between openbsd's systrace and selinux?
jamesm	I'm not very familiar with systrace, although it looks like it provides control over how applications use syscalls
jamesm	SELinux can control the use of syscalls, as part of an integrated security policy
jamesm	Some of the networking features planned for SELinux include:
jamesm	- Add controls for send/receive traffic by port.  (I'm working on this today :-)
jamesm	- Enhance local Unix sockets so that applications can authenticate
jamesm	each other using SELinux security credentials.
jamesm	(this is implemented, and under review by other developers)
jamesm	The Unix socket enhancement will be useful for integrating SELinux into X and for local IPC such as DBUS.
jamesm	but they are major topics themselves.
jamesm	- Making the network controls more expressive (they are powerful,
jamesm	but not as easy to use as e.g. iptables rules).
jamesm	- Labeled networking (this extends the security model over the
jamesm	network).
jamesm	- Better NFS support.
jamesm	- IPSec integration (e.g. security policy may specify protection
jamesm	requirements for network traffic).
jamesm	riel asked before about transporting the security contexts over the network.
jamesm	This is called labeled networking.
jamesm	Typically, each packet has a label attached (in SELinux, a security context).
jamesm	Or multiple labels (e.g. one indicating the security context of the sending process, one indicating the context of the message, and possibly one requesting that the destination process have a certain security context)
jamesm	This was implemented using IP options in an earlier version of SELinux, although it has been dropped, as the LSM hooks needed to support it were not accepted in the mainline kernel.
jamesm	An even earlier version was implemented before SELinux, using the predecessor Flask architecture.
jamesm	But instead of labeling each packet, IPSec connections were labeled
jamesm	so, each packet flowing over a given IPSec connection (more technically, each security association) had an implicit label.
jamesm	The security labeling was negotiated via an extension to ISAKMP (the key management protocol).
jamesm	Future packet labeling may revert to the IPSec based method.
jamesm	Labeled networking would probably only be useful in very high security environments where systems are under tight administrative control (e.g. telecomms)
jamesm	sydb asks: Why were the LSM hooks not included in mainline kernel (or were they just silently dropped?) Does IPSec method have big disadvantages?
jamesm	the LSM hooks for labeled networking were rejected by the maintainer as they were too invasive
jamesm	they were basically poking around inside network protocols
jamesm	we have been able to implement almost everything using other means (e.g. via Netfilter), so the decision looks to be sound so far :-)
jamesm	the IPSec method has two disadvantages (in my view).
jamesm	1) It makes IPSec more complicated, which is bad for security.
jamesm	2) It combines labeling and protection into the same mechanism
jamesm	this means that if you want labeling, you must have ipsec
jamesm	this is probably what most people actually want though
jamesm	(but some environments may do encryption on the wire, for example)
jamesm	overall though, after looking at both schemes, the IPsec system has some nice simplicity in that you just have to look at the SA (security association) that the packet belongs to, rather than parse IP options
jamesm	and IP options probably don't work on the real internet as many firewalls/routers will block them
jamesm	cdub asks: on inbound packets (say tcp accept) it's possible more than one process (or no process) is waiting for syn.  because processing happens in interrupt context, do you ever have problems with getting proper context to compare?
jamesm	yes, there are a couple of cases which we need to look at now that there are no hooks in the TCP code
jamesm	this may be solvable by doing a lookup, but needs more investigation
jamesm	ok, I have finished the material I planned to present, are there any more questions?
jamesm	cdub asks: i've had troubles with processes which can change security context getting data they sholdn't have access to
jamesm	in SELinux or just with LSM?
jamesm	for SELinux, you can only change security context on exec, so perhaps you are inheriting the socket?
jamesm	riel asks:  how is ipsec & selinux going to benefit normal system administrators, who can't set up complex security rules themselves ?
jamesm	good question
jamesm	firstly, for ipsec, it should be possible to simplify configuration for common uses, e.g. VPNs
jamesm	I think that is managable, e.g. IPSec is in wide use today
jamesm	for SELinux, it will be more difficult I think
jamesm	hopefully distributions will provide good policies for applications which normally don't need to be changed
jamesm	and common policy updates like adding users etc. will be wrapped in user friendly applications
jamesm	but I think that this is really the big unknown for SELinux
jamesm	and a very big challeng for Red Hat, Debian, Gentoo etc.
jamesm	challenge
jamesm	any more questions?
jamesm	nurbs asks: what do you mean by better NFS support?
jamesm	this can mean simply preserving the file security contexts over NFS, or more complicated, having the NFS server impose security policy on the remote filesystem as if it was local
jamesm	this needs to be implemented using extensions to NFSv2/3
jamesm	NFSv4 has more scope for this (e.g. you need Extended Attributes to be sent over the wire: these are how SELinux security contexts are implemented for files)
jamesm	but work needs to be done to both NFS and SELinux for this to work well
jamesm	the current NFS support is minimal: an nfs mounted filesystem appears locally with all files and directories having the same security context, and no security contexts are stored remotely
jamesm	ok, it looks like I am finished now :-)<riel> thank you James !
riel	clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
EMPE[log]	plas plas plas plas plas
riel	clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap
MJesus	clap clap clap clap clap clap clap clap clap clap

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net!

more information

© 2003 - www.uninet.edu - contact organizing comittee - valid xhtml - valid css - design by raul pérez justicia