Re: AppArmor FAQ
On Sun, 10 Jun 2007, Pavel Machek wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? This is exactly what AppArmor was designed to do, and without specifics, this is just FUD. No, it is not, I already broke AppArmor once, and it took me less then one hour. Give me machine with root shell, and make app armor permit everything but reading /etc/secret.file. AppArmor is not designed for this, but if you want to claim your solution works, this looks like a nice test. Actually, give password to everyone, and see who breaks it first. you admit that AA isn't designed for this and then you set this as the test, doesn't that seem unreasonable to you? httpd's run at root priviledge, AFAICT, and Crispin just accused someone of spreading fud. Exploited httpd is root shell. only poorly designed webservers run as root. in general they have not been running as root for many years. however, if you are willing to take a limited shell (root or any other user) that's a different story, what would you want the shell to have permission to do? would read files in directory A and write files in directory B be good enough? or would you want it to be able to execute specific commands? note that at the moment I am not comitting anyone to provide a box for such a challange, but I'm interested in what you would consider a suitable test. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Hi! > I'm not sure if AppArmor can be made good security for the general case, > but it is a model that works in the limited http environment > (eg .htaccess) and is something people can play with and hack on and may > be possible to configure to be very secure. > > >>>Perhaps -- until your httpd is compromised via a buffer overflow or > >>>simply misbehaves due to a software or configuration flaw, then the > >>>assumptions being made about its use of pathnames and their security > >>>properties are out the window. > >>> > >>How is it that you think a buffer overflow in httpd could allow an > >>attacker to break out of an AppArmor profile? This is exactly what > >>AppArmor was designed to do, and without specifics, this is just > >>FUD. > > > >No, it is not, I already broke AppArmor once, and it took me less then > >one hour. > > > >Give me machine with root shell, and make app armor permit everything > >but reading /etc/secret.file. AppArmor is not designed for this, but > >if you want to claim your solution works, this looks like a nice test. > > > >Actually, give password to everyone, and see who breaks it first. > > you admit that AA isn't designed for this and then you set this as the > test, doesn't that seem unreasonable to you? httpd's run at root priviledge, AFAICT, and Crispin just accused someone of spreading fud. Exploited httpd is root shell. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Sat, 9 Jun 2007, Pavel Machek wrote: Hi! I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? This is exactly what AppArmor was designed to do, and without specifics, this is just FUD. No, it is not, I already broke AppArmor once, and it took me less then one hour. Give me machine with root shell, and make app armor permit everything but reading /etc/secret.file. AppArmor is not designed for this, but if you want to claim your solution works, this looks like a nice test. Actually, give password to everyone, and see who breaks it first. you admit that AA isn't designed for this and then you set this as the test, doesn't that seem unreasonable to you? SELinux may be designed to protect against a local root user, AA is not. different tools, different tasks. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Hi! > >> I'm not sure if AppArmor can be made good security for the general case, > >> but it is a model that works in the limited http environment > >> (eg .htaccess) and is something people can play with and hack on and may > >> be possible to configure to be very secure. > >> > > Perhaps -- until your httpd is compromised via a buffer overflow or > > simply misbehaves due to a software or configuration flaw, then the > > assumptions being made about its use of pathnames and their security > > properties are out the window. > > > How is it that you think a buffer overflow in httpd could allow an > attacker to break out of an AppArmor profile? This is exactly what > AppArmor was designed to do, and without specifics, this is just > FUD. No, it is not, I already broke AppArmor once, and it took me less then one hour. Give me machine with root shell, and make app armor permit everything but reading /etc/secret.file. AppArmor is not designed for this, but if you want to claim your solution works, this looks like a nice test. Actually, give password to everyone, and see who breaks it first. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Hi! > >> Maybe you'd like to confine the PHP interpreter to limit what it can do. > >> That might be a good application for something like AppArmor. You don't > >> need comprehensive information flow control for that kind of use, and > >> it would likely just get in the way. > > > >SELinux can do this, it's policy-flexible. You can even simulate a > >pathame-based policy language with a consequential loss of control: > > I have no doubt that SELinux can do that, but that has about as much > relevance to my point as the price of tea in China does. I can use a > screwdriver to drive in a nail into my wall, too, if I really wanted to, > but that doesn't mean toolmakers should stop manufacturing hammers. Well, we are talking about kernel here, and if screwdrivers work well enough to drive nails into walls, we'll not allow hammers in. > My point is that there are some tasks where it's plausible that AppArmor > might well be a better (easier-to-use) tool for the job. I'm If SELinux can do the task, AA people are welcome to port their userland apps to SELinux to make it user friendly. We do _not_ provide user friendly services in kernel. Someone wanted shell inside kernel because it is convenient to him. Too bad, not going to be merged. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Hi! > >> Some may infer otherwise from your document. > >> > > Not only that, the implication that secrecy is only useful to > > intelligence agencies is pretty funny. > That was not the claim. Rather, that intelligence agencies have a very > strong need for privacy, and will go to greater lengths to get it, > including using MLS systems. I contend that while most organizations > want privacy, they don't want it so badly that they will put up with > MLS, and so are looking for a more tolerable form of security. > > This is relevant here because information flow is the main advantage of > labels over pathnames for access control. AppArmor does not attempt to > manage information flow, allowing it to use pathnames to achieve ease of > use. If you want information flow control, then by all means use a As SEEdit shows, you can still have ease-of-use with system capable of MLS so don't try to paint is as "pathnames are neccessary so it is easy to use". Just extend SELinux to handle new files. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Hi! Some may infer otherwise from your document. Not only that, the implication that secrecy is only useful to intelligence agencies is pretty funny. That was not the claim. Rather, that intelligence agencies have a very strong need for privacy, and will go to greater lengths to get it, including using MLS systems. I contend that while most organizations want privacy, they don't want it so badly that they will put up with MLS, and so are looking for a more tolerable form of security. This is relevant here because information flow is the main advantage of labels over pathnames for access control. AppArmor does not attempt to manage information flow, allowing it to use pathnames to achieve ease of use. If you want information flow control, then by all means use a As SEEdit shows, you can still have ease-of-use with system capable of MLS so don't try to paint is as pathnames are neccessary so it is easy to use. Just extend SELinux to handle new files. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Hi! Maybe you'd like to confine the PHP interpreter to limit what it can do. That might be a good application for something like AppArmor. You don't need comprehensive information flow control for that kind of use, and it would likely just get in the way. SELinux can do this, it's policy-flexible. You can even simulate a pathame-based policy language with a consequential loss of control: I have no doubt that SELinux can do that, but that has about as much relevance to my point as the price of tea in China does. I can use a screwdriver to drive in a nail into my wall, too, if I really wanted to, but that doesn't mean toolmakers should stop manufacturing hammers. Well, we are talking about kernel here, and if screwdrivers work well enough to drive nails into walls, we'll not allow hammers in. My point is that there are some tasks where it's plausible that AppArmor might well be a better (easier-to-use) tool for the job. I'm If SELinux can do the task, AA people are welcome to port their userland apps to SELinux to make it user friendly. We do _not_ provide user friendly services in kernel. Someone wanted shell inside kernel because it is convenient to him. Too bad, not going to be merged. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Hi! I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? This is exactly what AppArmor was designed to do, and without specifics, this is just FUD. No, it is not, I already broke AppArmor once, and it took me less then one hour. Give me machine with root shell, and make app armor permit everything but reading /etc/secret.file. AppArmor is not designed for this, but if you want to claim your solution works, this looks like a nice test. Actually, give password to everyone, and see who breaks it first. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Sat, 9 Jun 2007, Pavel Machek wrote: Hi! I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? This is exactly what AppArmor was designed to do, and without specifics, this is just FUD. No, it is not, I already broke AppArmor once, and it took me less then one hour. Give me machine with root shell, and make app armor permit everything but reading /etc/secret.file. AppArmor is not designed for this, but if you want to claim your solution works, this looks like a nice test. Actually, give password to everyone, and see who breaks it first. you admit that AA isn't designed for this and then you set this as the test, doesn't that seem unreasonable to you? SELinux may be designed to protect against a local root user, AA is not. different tools, different tasks. David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Hi! I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? This is exactly what AppArmor was designed to do, and without specifics, this is just FUD. No, it is not, I already broke AppArmor once, and it took me less then one hour. Give me machine with root shell, and make app armor permit everything but reading /etc/secret.file. AppArmor is not designed for this, but if you want to claim your solution works, this looks like a nice test. Actually, give password to everyone, and see who breaks it first. you admit that AA isn't designed for this and then you set this as the test, doesn't that seem unreasonable to you? httpd's run at root priviledge, AFAICT, and Crispin just accused someone of spreading fud. Exploited httpd is root shell. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Sun, 10 Jun 2007, Pavel Machek wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? This is exactly what AppArmor was designed to do, and without specifics, this is just FUD. No, it is not, I already broke AppArmor once, and it took me less then one hour. Give me machine with root shell, and make app armor permit everything but reading /etc/secret.file. AppArmor is not designed for this, but if you want to claim your solution works, this looks like a nice test. Actually, give password to everyone, and see who breaks it first. you admit that AA isn't designed for this and then you set this as the test, doesn't that seem unreasonable to you? httpd's run at root priviledge, AFAICT, and Crispin just accused someone of spreading fud. Exploited httpd is root shell. only poorly designed webservers run as root. in general they have not been running as root for many years. however, if you are willing to take a limited shell (root or any other user) that's a different story, what would you want the shell to have permission to do? would read files in directory A and write files in directory B be good enough? or would you want it to be able to execute specific commands? note that at the moment I am not comitting anyone to provide a box for such a challange, but I'm interested in what you would consider a suitable test. David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Crispin Cowan wrote: David Wagner wrote: James Morris wrote: [...] you can change the behavior of the application and then bypass policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc. [...] Just look at their code and their own description of AppArmor. My gosh, you're right. What the heck? With all due respect to the developers of AppArmor, I can't help thinking that that's pretty lame. I think this raises substantial questions about the value of AppArmor. What is the point of having a jail if it leaves gaping holes that malicious code could use to escape? And why isn't this documented clearly, with the implications fully explained? I would like to hear the AppArmor developers defend this design decision. It was a simplicity trade off at the time, when AppArmor was mostly aimed at servers, and there was no HAL or DBUS. Now it is definitely a limitation that we are addressing. We are working on a mediation system for what kind of IPC a confined process can do http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html Also, things like: share_mem /usr/bin/firefox r,# /bin/foo can share memory with /usr/bin/firefox for read only clearly show that you aren't using native abstractions for IPC. The native abstraction for shared memory would be the key used when creating the shared memory segment. The same goes for message queues which are noticeably missing from the "simplified" IPC model. This, of course, begs the question of whether you are using native abstractions for profiles at all, processes have nothing to do with the binary they started from after they've been started. The binary on disk could be something entirely different than the process from which it ran. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Crispin Cowan wrote: David Wagner wrote: James Morris wrote: [...] you can change the behavior of the application and then bypass policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc. [...] Just look at their code and their own description of AppArmor. My gosh, you're right. What the heck? With all due respect to the developers of AppArmor, I can't help thinking that that's pretty lame. I think this raises substantial questions about the value of AppArmor. What is the point of having a jail if it leaves gaping holes that malicious code could use to escape? And why isn't this documented clearly, with the implications fully explained? I would like to hear the AppArmor developers defend this design decision. It was a simplicity trade off at the time, when AppArmor was mostly aimed at servers, and there was no HAL or DBUS. Now it is definitely a limitation that we are addressing. We are working on a mediation system for what kind of IPC a confined process can do http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html Also, things like: share_mem /usr/bin/firefox r,# /bin/foo can share memory with /usr/bin/firefox for read only clearly show that you aren't using native abstractions for IPC. The native abstraction for shared memory would be the key used when creating the shared memory segment. The same goes for message queues which are noticeably missing from the simplified IPC model. This, of course, begs the question of whether you are using native abstractions for profiles at all, processes have nothing to do with the binary they started from after they've been started. The binary on disk could be something entirely different than the process from which it ran. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Crispin Cowan wrote: David Wagner wrote: James Morris wrote: [...] you can change the behavior of the application and then bypass policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc. [...] Just look at their code and their own description of AppArmor. My gosh, you're right. What the heck? With all due respect to the developers of AppArmor, I can't help thinking that that's pretty lame. I think this raises substantial questions about the value of AppArmor. What is the point of having a jail if it leaves gaping holes that malicious code could use to escape? And why isn't this documented clearly, with the implications fully explained? I would like to hear the AppArmor developers defend this design decision. It was a simplicity trade off at the time, when AppArmor was mostly aimed at servers, and there was no HAL or DBUS. Now it is definitely a limitation that we are addressing. We are working on a mediation system for what kind of IPC a confined process can do http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html Except servers use IPC and need this access control as well. Without IPC and network restrictions you can't protect database servers, ldap servers, print servers, ssh agents, virus scanning servers, spam scanning servers, etc from attackers with knowledge of how to abuse the IPC. When our IPC mediation system is code instead of vapor, it will also appear here for review. Meanwhile, AppArmor does not make IPC security any worse, confined processes are still subject to the usual Linux IPC restrictions. AppArmor actually makes the IPC situation somewhat more secure than stock Linux, e.g. normal DBUS deployment can be controlled through file access permissions. But we are not claiming AppArmor to be an IPC security enhancement, yet. Without a security interface in DBUS similar to SELinux' apparmor won't be able to control who can talk to who across DBUS, only who can connect to DBUS directly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
David Wagner wrote: > James Morris wrote: > >> [...] you can change the behavior of the application and then bypass >> policy entirely by utilizing any mechanism other than direct filesystem >> access: IPC, shared memory, Unix domain sockets, local IP networking, >> remote networking etc. >> > [...] > >> Just look at their code and their own description of AppArmor. >> > My gosh, you're right. What the heck? With all due respect to the > developers of AppArmor, I can't help thinking that that's pretty lame. > I think this raises substantial questions about the value of AppArmor. > What is the point of having a jail if it leaves gaping holes that > malicious code could use to escape? > > And why isn't this documented clearly, with the implications fully > explained? > > I would like to hear the AppArmor developers defend this design decision. > It was a simplicity trade off at the time, when AppArmor was mostly aimed at servers, and there was no HAL or DBUS. Now it is definitely a limitation that we are addressing. We are working on a mediation system for what kind of IPC a confined process can do http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html When our IPC mediation system is code instead of vapor, it will also appear here for review. Meanwhile, AppArmor does not make IPC security any worse, confined processes are still subject to the usual Linux IPC restrictions. AppArmor actually makes the IPC situation somewhat more secure than stock Linux, e.g. normal DBUS deployment can be controlled through file access permissions. But we are not claiming AppArmor to be an IPC security enhancement, yet. The proposed set of patches is a self-contained access control system for file system access, and we would like it reviewed as such. Current AppArmor docs are quite explicit that AppArmor only mediates file access and POSIX.1e capabilities. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
David Wagner wrote: James Morris wrote: [...] you can change the behavior of the application and then bypass policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc. [...] Just look at their code and their own description of AppArmor. My gosh, you're right. What the heck? With all due respect to the developers of AppArmor, I can't help thinking that that's pretty lame. I think this raises substantial questions about the value of AppArmor. What is the point of having a jail if it leaves gaping holes that malicious code could use to escape? And why isn't this documented clearly, with the implications fully explained? I would like to hear the AppArmor developers defend this design decision. It was a simplicity trade off at the time, when AppArmor was mostly aimed at servers, and there was no HAL or DBUS. Now it is definitely a limitation that we are addressing. We are working on a mediation system for what kind of IPC a confined process can do http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html When our IPC mediation system is code instead of vapor, it will also appear here for review. Meanwhile, AppArmor does not make IPC security any worse, confined processes are still subject to the usual Linux IPC restrictions. AppArmor actually makes the IPC situation somewhat more secure than stock Linux, e.g. normal DBUS deployment can be controlled through file access permissions. But we are not claiming AppArmor to be an IPC security enhancement, yet. The proposed set of patches is a self-contained access control system for file system access, and we would like it reviewed as such. Current AppArmor docs are quite explicit that AppArmor only mediates file access and POSIX.1e capabilities. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Crispin Cowan wrote: David Wagner wrote: James Morris wrote: [...] you can change the behavior of the application and then bypass policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc. [...] Just look at their code and their own description of AppArmor. My gosh, you're right. What the heck? With all due respect to the developers of AppArmor, I can't help thinking that that's pretty lame. I think this raises substantial questions about the value of AppArmor. What is the point of having a jail if it leaves gaping holes that malicious code could use to escape? And why isn't this documented clearly, with the implications fully explained? I would like to hear the AppArmor developers defend this design decision. It was a simplicity trade off at the time, when AppArmor was mostly aimed at servers, and there was no HAL or DBUS. Now it is definitely a limitation that we are addressing. We are working on a mediation system for what kind of IPC a confined process can do http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html Except servers use IPC and need this access control as well. Without IPC and network restrictions you can't protect database servers, ldap servers, print servers, ssh agents, virus scanning servers, spam scanning servers, etc from attackers with knowledge of how to abuse the IPC. When our IPC mediation system is code instead of vapor, it will also appear here for review. Meanwhile, AppArmor does not make IPC security any worse, confined processes are still subject to the usual Linux IPC restrictions. AppArmor actually makes the IPC situation somewhat more secure than stock Linux, e.g. normal DBUS deployment can be controlled through file access permissions. But we are not claiming AppArmor to be an IPC security enhancement, yet. Without a security interface in DBUS similar to SELinux' apparmor won't be able to control who can talk to who across DBUS, only who can connect to DBUS directly. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Fri, 2007-04-20 at 11:45 -0700, David Lang wrote: > On Thu, 19 Apr 2007, Stephen Smalley wrote: > > > already happened to integrate such support into userland. > > > > To look at it in a slightly different way, the AA emphasis on not > > modifying applications could be viewed as a limitation. Ultimately, > > users have security goals that go beyond just what the OS can directly > > enforce and at least some applications (notably things like X, D-BUS, > > PostgreSQL, etc) need to likewise support strong domain separation and > > controlled information flow through their own internal objects and > > operations. SELinux provides APIs and infrastructure for such > > applications, and has already done quite a bit of work in that space > > (D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have > > no interest in going there (and would have to recant its emphasis on no > > application mods to do so). If you actually want to truly confine a > > desktop application, you can't limit yourself to the kernel. And the >^^^ > > > label model provides a unifying abstraction for dealing with all of > > these various objects, whereas the path/"natural abstraction" model has > > no unifying abstraction at all. > > > AA isn't aimed at confineing desktop applications. it's aimed at confining > server applications. this really is a easier task (if it happens to be useful > for some desktop apps as well, so much the better) > Steve's point holds equally well for server applications - SE-PostgreSQl is a good example. Karl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 19 Apr 2007, Stephen Smalley wrote: already happened to integrate such support into userland. To look at it in a slightly different way, the AA emphasis on not modifying applications could be viewed as a limitation. Ultimately, users have security goals that go beyond just what the OS can directly enforce and at least some applications (notably things like X, D-BUS, PostgreSQL, etc) need to likewise support strong domain separation and controlled information flow through their own internal objects and operations. SELinux provides APIs and infrastructure for such applications, and has already done quite a bit of work in that space (D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have no interest in going there (and would have to recant its emphasis on no application mods to do so). If you actually want to truly confine a desktop application, you can't limit yourself to the kernel. And the ^^^ label model provides a unifying abstraction for dealing with all of these various objects, whereas the path/"natural abstraction" model has no unifying abstraction at all. AA isn't aimed at confineing desktop applications. it's aimed at confining server applications. this really is a easier task (if it happens to be useful for some desktop apps as well, so much the better) David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 19 Apr 2007, Stephen Smalley wrote: already happened to integrate such support into userland. To look at it in a slightly different way, the AA emphasis on not modifying applications could be viewed as a limitation. Ultimately, users have security goals that go beyond just what the OS can directly enforce and at least some applications (notably things like X, D-BUS, PostgreSQL, etc) need to likewise support strong domain separation and controlled information flow through their own internal objects and operations. SELinux provides APIs and infrastructure for such applications, and has already done quite a bit of work in that space (D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have no interest in going there (and would have to recant its emphasis on no application mods to do so). If you actually want to truly confine a desktop application, you can't limit yourself to the kernel. And the ^^^ label model provides a unifying abstraction for dealing with all of these various objects, whereas the path/natural abstraction model has no unifying abstraction at all. AA isn't aimed at confineing desktop applications. it's aimed at confining server applications. this really is a easier task (if it happens to be useful for some desktop apps as well, so much the better) David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Fri, 2007-04-20 at 11:45 -0700, David Lang wrote: On Thu, 19 Apr 2007, Stephen Smalley wrote: already happened to integrate such support into userland. To look at it in a slightly different way, the AA emphasis on not modifying applications could be viewed as a limitation. Ultimately, users have security goals that go beyond just what the OS can directly enforce and at least some applications (notably things like X, D-BUS, PostgreSQL, etc) need to likewise support strong domain separation and controlled information flow through their own internal objects and operations. SELinux provides APIs and infrastructure for such applications, and has already done quite a bit of work in that space (D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have no interest in going there (and would have to recant its emphasis on no application mods to do so). If you actually want to truly confine a desktop application, you can't limit yourself to the kernel. And the ^^^ label model provides a unifying abstraction for dealing with all of these various objects, whereas the path/natural abstraction model has no unifying abstraction at all. AA isn't aimed at confineing desktop applications. it's aimed at confining server applications. this really is a easier task (if it happens to be useful for some desktop apps as well, so much the better) Steve's point holds equally well for server applications - SE-PostgreSQl is a good example. Karl - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 2007-04-19 at 20:54 +, David Wagner wrote:
> Stephen Smalley wrote:
> >Integrity protection requires information flow control; you can't
> >protect a high integrity process from being corrupted by a low integrity
> >process if you don't control the flow of information. Plenty of attacks
> >take the form of a untrusted process injecting data that will ultimately
> >be used by a more trusted process with a surprising side effect.
>
> I don't agree with this blanket statement. In a number of cases
> of practical interest, useful integrity protection can be achieved
> without full information flow control. Suppose you have a malicious
> ("low integrity") process A, and a target ("high integrity") process B.
> We want to prevent A from attacking B. One way to do that is to ensure
> that A has no overt channel it can use to attack process B, by severely
> restricting A's ability to cause side effects on the rest of the world.
> This is often sufficient to contain the damage that A can do.
If you could do that, I'd call that information flow control - I wasn't
saying you had to eliminate covert channels. As you said, we don't deal
with those even in SELinux. The point is that AA can't even do that,
not only because it has incomplete controls but because it bases its
decisions on unreliable identifiers (paths) that doesn't let it provide
global and persistent protection of the data.
> Of course, if the intended functionality of the system requires A to
> communicate data to B, and if you don't trust B's ability to handle
> that data carefully enough, and if A is malicious, then you've got a
> serious problem.
>
> But in a number of cases (enough cases to be useful), you can provide
> a useful level of security without needing information flow control and
> without needing global, persistent labels.
Without a reliable way of identifying the data in a system view, you
can't say anything at all about the data flows. The labels provide you
with a way of doing that. The paths are ambiguous, highly mutable, and
often meaningless (particularly for runtime files, temporary files, etc)
from a security pov.
Simple example: malicious symlink attacks.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 19 Apr 2007, Stephen Smalley wrote: > Lastly, if you want to judge AA as a jail mechanism, I think you'll find > it fails there too. So where does that leave it? An easy-to-use yet > inadequate solution for MAC or jail. It's not easy to use. -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 2007-04-19 at 20:08 +, David Wagner wrote: > Stephen Smalley wrote: > >Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM > >Vol 16 No 10) means information flow control, which you have agreed > >AppArmor does not and cannot provide. > > Right, that's how I understand it, too. > > However, I think some more caveats are in order. In all honesty, > I don't think SELinux solves Lampson's problem, either. > > It is useful to distinguish between "bit-confinement" (confining the > flow of information, a la Lampson) vs "authority-confinement" (confining > the flow of privileges and the ability of the untrusted app to cause > side effects on the rest of the system). > > No Linux system provides bit-confinement, if the confined app is > malicious. AppArmor does not provide bit-confinement. Neither does > SELinux. SELinux can stop some kinds of accidental leakage of secrets, > but it cannot prevent deliberate attempts to leak the secrets that are > known to malicious apps. The reason is that, in every system under > consideration, it is easy for a malicious app to leak any secrets it might > have to the outside world by using covert channels (e.g., wall-banging). > In practical terms, Lampson's bit-confinement problem is just not > solvable. Oh well, so it goes. > > A good jail needs to provide authority-confinement, but thankfully, > it doesn't need to provide bit-confinement. I don't know enough about > AppArmor to know whether it is able to do a good job of providing > authority-confinement. If it cannot, then it deserves criticism on > those grounds. > > Often the pragmatic solution to the covert channel problem is to ensure > that untrusted apps are never given access to critical secrets in the > first place. They can't leak something they don't know. This solves the > confidentiality problem by avoiding any attempt to tackle the unsolvable > bit-confinement problem. > > Note that the problem of building a good jail is a little different from > the information flow control problem. First, I think there is practical value in providing confidentiality control on the overt channels, even if covert channels remain. We have to start somewhere. Second, information flow is not just a confidentiality issue - see my other email. It is quite important as well for integrity, and integrity corruption in order to assume control over a privileged subject or trick it into abusing its power can be done solely via a data channel - it doesn't require explicit flow of authority. Lastly, if you want to judge AA as a jail mechanism, I think you'll find it fails there too. So where does that leave it? An easy-to-use yet inadequate solution for MAC or jail. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Stephen Smalley wrote:
>Integrity protection requires information flow control; you can't
>protect a high integrity process from being corrupted by a low integrity
>process if you don't control the flow of information. Plenty of attacks
>take the form of a untrusted process injecting data that will ultimately
>be used by a more trusted process with a surprising side effect.
I don't agree with this blanket statement. In a number of cases
of practical interest, useful integrity protection can be achieved
without full information flow control. Suppose you have a malicious
("low integrity") process A, and a target ("high integrity") process B.
We want to prevent A from attacking B. One way to do that is to ensure
that A has no overt channel it can use to attack process B, by severely
restricting A's ability to cause side effects on the rest of the world.
This is often sufficient to contain the damage that A can do.
Of course, if the intended functionality of the system requires A to
communicate data to B, and if you don't trust B's ability to handle
that data carefully enough, and if A is malicious, then you've got a
serious problem.
But in a number of cases (enough cases to be useful), you can provide
a useful level of security without needing information flow control and
without needing global, persistent labels.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Crispin Cowan wrote: > How is it that you think a buffer overflow in httpd could allow an > attacker to break out of an AppArmor profile? James Morris wrote: > [...] you can change the behavior of the application and then bypass > policy entirely by utilizing any mechanism other than direct filesystem > access: IPC, shared memory, Unix domain sockets, local IP networking, > remote networking etc. [...] > Just look at their code and their own description of AppArmor. My gosh, you're right. What the heck? With all due respect to the developers of AppArmor, I can't help thinking that that's pretty lame. I think this raises substantial questions about the value of AppArmor. What is the point of having a jail if it leaves gaping holes that malicious code could use to escape? And why isn't this documented clearly, with the implications fully explained? I would like to hear the AppArmor developers defend this design decision. When we developed Janus, over 10 years ago, we defended against these attack avenues and protected everything -- not just the filesystem. Systrace does the same, as does Plash. So does Consh, and MapBox, and Ostia, to name a few other examples from the research world. This is standard stuff that is well-documented in the literature, and it seems to me it is necessary before you can claim to have a useful jail. What am I missing? P.S. I think the criticisms that "AppArmor is pathname-based" or "AppArmor doesn't do everything SELinux does" or "AppArmor doesn't do information flow control" are weak. But the criticism that "AppArmor leaves security holes that can be used to escape the jail" seems like a serious criticism to me. Perhaps a change of focus is in order. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 19 Apr 2007, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > Perhaps -- until your httpd is compromised via a buffer overflow or > > simply misbehaves due to a software or configuration flaw, then the > > assumptions being made about its use of pathnames and their security > > properties are out the window. > > Hu? Even a compromised httpd (especially a compromised httpd) is bound to > the app armor policies. This means it cannot (for example) write to > /var/www/* - if it never needed to at normal/profiling time. This has been addressed several times already, please read the full thread. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Stephen Smalley wrote: >Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM >Vol 16 No 10) means information flow control, which you have agreed >AppArmor does not and cannot provide. Right, that's how I understand it, too. However, I think some more caveats are in order. In all honesty, I don't think SELinux solves Lampson's problem, either. It is useful to distinguish between "bit-confinement" (confining the flow of information, a la Lampson) vs "authority-confinement" (confining the flow of privileges and the ability of the untrusted app to cause side effects on the rest of the system). No Linux system provides bit-confinement, if the confined app is malicious. AppArmor does not provide bit-confinement. Neither does SELinux. SELinux can stop some kinds of accidental leakage of secrets, but it cannot prevent deliberate attempts to leak the secrets that are known to malicious apps. The reason is that, in every system under consideration, it is easy for a malicious app to leak any secrets it might have to the outside world by using covert channels (e.g., wall-banging). In practical terms, Lampson's bit-confinement problem is just not solvable. Oh well, so it goes. A good jail needs to provide authority-confinement, but thankfully, it doesn't need to provide bit-confinement. I don't know enough about AppArmor to know whether it is able to do a good job of providing authority-confinement. If it cannot, then it deserves criticism on those grounds. Often the pragmatic solution to the covert channel problem is to ensure that untrusted apps are never given access to critical secrets in the first place. They can't leak something they don't know. This solves the confidentiality problem by avoiding any attempt to tackle the unsolvable bit-confinement problem. Note that the problem of building a good jail is a little different from the information flow control problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
In article <[EMAIL PROTECTED]> you wrote: > Perhaps -- until your httpd is compromised via a buffer overflow or > simply misbehaves due to a software or configuration flaw, then the > assumptions being made about its use of pathnames and their security > properties are out the window. Hu? Even a compromised httpd (especially a compromised httpd) is bound to the app armor policies. This means it cannot (for example) write to /var/www/* - if it never needed to at normal/profiling time. Gruss Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote: > David Safford wrote: > > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: > > > >> On Mon, 16 Apr 2007, John Johansen wrote: > >> > >>> Label-based security (exemplified by SELinux, and its predecessors in > >>> MLS systems) attaches security policy to the data. As the data flows > >>> through the system, the label sticks to the data, and so security > >>> policy with respect to this data stays intact. This is a good approach > >>> for ensuring secrecy, the kind of problem that intelligence agencies have. > >>> > >> Labels are also a good approach for ensuring integrity, which is one of > >> the most fundamental aspects of the security model implemented by SELinux. > >> > >> > >> Some may infer otherwise from your document. > >> > > In fact, I am not sure how you can provide integrity support without > > labels. AppArmor confines a process, but does not effectively confine > > its output files, precisely because the output files are not labeled. > > Other processes are free to access the unlabeled, potentially malicious > > output files without restriction. > > > That depends on what you mean by "integrity." It is true that AppArmor > does not directly manage information flow. AppArmor assumes that if you > granted write permission to /etc/resolv.conf, that you meant to do that. > Whether any other process is permitted to access /etc/resolv.conf is > determined by those other process's respective profiles. Integrity protection requires information flow control; you can't protect a high integrity process from being corrupted by a low integrity process if you don't control the flow of information. Plenty of attacks take the form of a untrusted process injecting data that will ultimately be used by a more trusted process with a surprising side effect. And you can't do information flow control if you can't provide global and persistent protection of the data, which requires labeling it and preserving that label for its lifetime. > What AppArmor provides is a way for administrators to confine software > that they have to run but do not trust. The use of pathnames means that > the administrator can understand the exact meaning of the security > policy, without having to do a complete labeling of the file system. The > flip side of not managing information flow is that each profile is > independent of every other profile. They aren't truly independent; the composition may lead to surprising results where each individual program is "confined" exactly as you specified, but in combination, one is able to corrupt the higher integrity subject by actions taken by the lower integrity subject. Particularly in the fun area of publically writable directories, where pathnames are largely useless as an indicator. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 20:05 +0200, Andi Kleen wrote: > Karl MacMillan <[EMAIL PROTECTED]> writes: > > > No - the real fix is to change the applications or to run under a policy > > that confines all applications. Most of the problems with resolv.conf, > > mtab, etc. stem from admin processes (e.g., editors or shell scripts) > > all running under the same unconfined domain. > > > > In some cases applications need modification as only the application has > > enough information to determine the correct label. Usually this means > > preserving labels from input files or separating the output into > > distinct directories so type transitions or label inheritance will work. > > > > restorecond is just a hack not a requirement or a sign that something is > > wrong with the model. That is why it is a userspace application and not > > integrated into the kernel mechanism. > > You nicely show one of the major disadvantages of the label model vs the path > model here: it requires modification of a lot of applications. It is true that many applications that already deal with mode bits need to become aware of labels, just as with ACLs, and that this makes it a bit harder and slower to roll out something that is label-based. But the right solution is rarely quick and easy, and a lot of work has already happened to integrate such support into userland. To look at it in a slightly different way, the AA emphasis on not modifying applications could be viewed as a limitation. Ultimately, users have security goals that go beyond just what the OS can directly enforce and at least some applications (notably things like X, D-BUS, PostgreSQL, etc) need to likewise support strong domain separation and controlled information flow through their own internal objects and operations. SELinux provides APIs and infrastructure for such applications, and has already done quite a bit of work in that space (D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have no interest in going there (and would have to recant its emphasis on no application mods to do so). If you actually want to truly confine a desktop application, you can't limit yourself to the kernel. And the label model provides a unifying abstraction for dealing with all of these various objects, whereas the path/"natural abstraction" model has no unifying abstraction at all. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 2007-04-19 at 16:35 +, David Wagner wrote: > James Morris wrote: > >On Wed, 18 Apr 2007, Crispin Cowan wrote: > >> How is it that you think a buffer overflow in httpd could allow an > >> attacker to break out of an AppArmor profile? > > > >Because you can change the behavior of the application and then bypass > >policy entirely by utilizing any mechanism other than direct filesystem > >access: IPC, shared memory, Unix domain sockets, local IP networking, > >remote networking etc. > > Any halfway decent jail will let you control access to all of those > things, thereby preventing an 0wned httpd from breaking out of the jail. > (For instance, Janus did. So does Systrace.) > > Are you saying AppArmor does not allow that kind of control? Specifics > would be useful. Just look at their code and their own description of AppArmor. It does not provide that level of control, and by your own metric, it is thus not a halfway decent jail. Which begs the question - if that is the kind of approach you want, why not use a real jail/containers mechanism for it? > >Also worth noting here is that you have to consider any limited > >environment as enforcing security policy, and thus its configuration > >becomes an additional component of security policy. > > I don't understand what you are saying. Yes, the AppArmor policy > file is part of policy. Is that what you mean? I think he means the dependencies on which AppArmor relies, not just its policy, e.g. since it is name-based, it presumes the filesystem namespace has been set up by a trusted agent and is correct. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 2007-04-18 at 13:15 -0700, David Lang wrote: > On Wed, 18 Apr 2007, James Morris wrote: > > > On Tue, 17 Apr 2007, Alan Cox wrote: > > > >> I'm not sure if AppArmor can be made good security for the general case, > >> but it is a model that works in the limited http environment > >> (eg .htaccess) and is something people can play with and hack on and may > >> be possible to configure to be very secure. > > > > Perhaps -- until your httpd is compromised via a buffer overflow or > > simply misbehaves due to a software or configuration flaw, then the > > assumptions being made about its use of pathnames and their security > > properties are out the window. > > since AA defines a whitelist of files that httpd is allowed to access, a > comprimised one may be able to mess up it's files, but it's still not going > to > be able to touch other files on the system. > > > Without security labeling of the objects being accessed, you can't protect > > against software flaws, which has been a pretty fundamental and widely > > understood requirement in general computing for at least a decade. > > this is not true. you don't need to label all object and chunks of memory, > you > just need to have a way to list (and enforce) the objects and memory that the > program is allowed to use. labeling them is one way of doing this, but not > the > only way. You need a way of providing global and persistent security guarantees for the data, and per-program profiles based on pathname don't get you there. There is no system view in AA, just a bunch of disconnected profiles. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 2007-04-18 at 12:41 -0700, Crispin Cowan wrote: > James Morris wrote: > > On Tue, 17 Apr 2007, Alan Cox wrote: > > > >> I'm not sure if AppArmor can be made good security for the general case, > >> but it is a model that works in the limited http environment > >> (eg .htaccess) and is something people can play with and hack on and may > >> be possible to configure to be very secure. > >> > > Perhaps -- until your httpd is compromised via a buffer overflow or > > simply misbehaves due to a software or configuration flaw, then the > > assumptions being made about its use of pathnames and their security > > properties are out the window. > > > How is it that you think a buffer overflow in httpd could allow an > attacker to break out of an AppArmor profile? This is exactly what > AppArmor was designed to do, and without specifics, this is just FUD. > > > Without security labeling of the objects being accessed, you can't protect > > against software flaws, which has been a pretty fundamental and widely > > understood requirement in general computing for at least a decade. > > > Please explain why labels are necessary for effective confinement. Many > systems besides AppArmor have used non-label schemes for effective > confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS, > AS400, to name just a few. This claim seems bogus. Labels may be your > method of choice for confinement, but they are far from the only way. Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM Vol 16 No 10) means information flow control, which you have agreed AppArmor does not and cannot provide. Yes? As to the (genuine) capability-based systems, have a look at the DTOS General System Security and Assurability Assessment Report for why we have concerns with their approach. But that has nothing to do with AppArmor. Look, if you would just refrain from making misleading statements about SELinux (not only in this FAQ but throughout your documents and talks), especially when we've previously refuted those same statements (as in the first AppArmor submission and its discussion), and honestly acknowledged the limitations of your approach without trying to spin them as strengths, I think that there would be nothing to discuss here. We could just agree to disagree, and you could just focus on addressing the issues raised by the vfs folks about how to get your changes into an acceptable form. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: >On Wed, 18 Apr 2007, Crispin Cowan wrote: >> How is it that you think a buffer overflow in httpd could allow an >> attacker to break out of an AppArmor profile? > >Because you can change the behavior of the application and then bypass >policy entirely by utilizing any mechanism other than direct filesystem >access: IPC, shared memory, Unix domain sockets, local IP networking, >remote networking etc. Any halfway decent jail will let you control access to all of those things, thereby preventing an 0wned httpd from breaking out of the jail. (For instance, Janus did. So does Systrace.) Are you saying AppArmor does not allow that kind of control? Specifics would be useful. >Also worth noting here is that you have to consider any limited >environment as enforcing security policy, and thus its configuration >becomes an additional component of security policy. I don't understand what you are saying. Yes, the AppArmor policy file is part of policy. Is that what you mean? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: On Wed, 18 Apr 2007, Crispin Cowan wrote: How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? Because you can change the behavior of the application and then bypass policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc. Any halfway decent jail will let you control access to all of those things, thereby preventing an 0wned httpd from breaking out of the jail. (For instance, Janus did. So does Systrace.) Are you saying AppArmor does not allow that kind of control? Specifics would be useful. Also worth noting here is that you have to consider any limited environment as enforcing security policy, and thus its configuration becomes an additional component of security policy. I don't understand what you are saying. Yes, the AppArmor policy file is part of policy. Is that what you mean? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 2007-04-18 at 12:41 -0700, Crispin Cowan wrote: James Morris wrote: On Tue, 17 Apr 2007, Alan Cox wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? This is exactly what AppArmor was designed to do, and without specifics, this is just FUD. Without security labeling of the objects being accessed, you can't protect against software flaws, which has been a pretty fundamental and widely understood requirement in general computing for at least a decade. Please explain why labels are necessary for effective confinement. Many systems besides AppArmor have used non-label schemes for effective confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS, AS400, to name just a few. This claim seems bogus. Labels may be your method of choice for confinement, but they are far from the only way. Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM Vol 16 No 10) means information flow control, which you have agreed AppArmor does not and cannot provide. Yes? As to the (genuine) capability-based systems, have a look at the DTOS General System Security and Assurability Assessment Report for why we have concerns with their approach. But that has nothing to do with AppArmor. Look, if you would just refrain from making misleading statements about SELinux (not only in this FAQ but throughout your documents and talks), especially when we've previously refuted those same statements (as in the first AppArmor submission and its discussion), and honestly acknowledged the limitations of your approach without trying to spin them as strengths, I think that there would be nothing to discuss here. We could just agree to disagree, and you could just focus on addressing the issues raised by the vfs folks about how to get your changes into an acceptable form. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 2007-04-18 at 13:15 -0700, David Lang wrote: On Wed, 18 Apr 2007, James Morris wrote: On Tue, 17 Apr 2007, Alan Cox wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. since AA defines a whitelist of files that httpd is allowed to access, a comprimised one may be able to mess up it's files, but it's still not going to be able to touch other files on the system. Without security labeling of the objects being accessed, you can't protect against software flaws, which has been a pretty fundamental and widely understood requirement in general computing for at least a decade. this is not true. you don't need to label all object and chunks of memory, you just need to have a way to list (and enforce) the objects and memory that the program is allowed to use. labeling them is one way of doing this, but not the only way. You need a way of providing global and persistent security guarantees for the data, and per-program profiles based on pathname don't get you there. There is no system view in AA, just a bunch of disconnected profiles. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 2007-04-19 at 16:35 +, David Wagner wrote: James Morris wrote: On Wed, 18 Apr 2007, Crispin Cowan wrote: How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? Because you can change the behavior of the application and then bypass policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc. Any halfway decent jail will let you control access to all of those things, thereby preventing an 0wned httpd from breaking out of the jail. (For instance, Janus did. So does Systrace.) Are you saying AppArmor does not allow that kind of control? Specifics would be useful. Just look at their code and their own description of AppArmor. It does not provide that level of control, and by your own metric, it is thus not a halfway decent jail. Which begs the question - if that is the kind of approach you want, why not use a real jail/containers mechanism for it? Also worth noting here is that you have to consider any limited environment as enforcing security policy, and thus its configuration becomes an additional component of security policy. I don't understand what you are saying. Yes, the AppArmor policy file is part of policy. Is that what you mean? I think he means the dependencies on which AppArmor relies, not just its policy, e.g. since it is name-based, it presumes the filesystem namespace has been set up by a trusted agent and is correct. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 20:05 +0200, Andi Kleen wrote: Karl MacMillan [EMAIL PROTECTED] writes: No - the real fix is to change the applications or to run under a policy that confines all applications. Most of the problems with resolv.conf, mtab, etc. stem from admin processes (e.g., editors or shell scripts) all running under the same unconfined domain. In some cases applications need modification as only the application has enough information to determine the correct label. Usually this means preserving labels from input files or separating the output into distinct directories so type transitions or label inheritance will work. restorecond is just a hack not a requirement or a sign that something is wrong with the model. That is why it is a userspace application and not integrated into the kernel mechanism. You nicely show one of the major disadvantages of the label model vs the path model here: it requires modification of a lot of applications. It is true that many applications that already deal with mode bits need to become aware of labels, just as with ACLs, and that this makes it a bit harder and slower to roll out something that is label-based. But the right solution is rarely quick and easy, and a lot of work has already happened to integrate such support into userland. To look at it in a slightly different way, the AA emphasis on not modifying applications could be viewed as a limitation. Ultimately, users have security goals that go beyond just what the OS can directly enforce and at least some applications (notably things like X, D-BUS, PostgreSQL, etc) need to likewise support strong domain separation and controlled information flow through their own internal objects and operations. SELinux provides APIs and infrastructure for such applications, and has already done quite a bit of work in that space (D-BUS support, XACE/XSELinux, SE-PostgreSQL), whereas AA seems to have no interest in going there (and would have to recant its emphasis on no application mods to do so). If you actually want to truly confine a desktop application, you can't limit yourself to the kernel. And the label model provides a unifying abstraction for dealing with all of these various objects, whereas the path/natural abstraction model has no unifying abstraction at all. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote: David Safford wrote: On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: On Mon, 16 Apr 2007, John Johansen wrote: Label-based security (exemplified by SELinux, and its predecessors in MLS systems) attaches security policy to the data. As the data flows through the system, the label sticks to the data, and so security policy with respect to this data stays intact. This is a good approach for ensuring secrecy, the kind of problem that intelligence agencies have. Labels are also a good approach for ensuring integrity, which is one of the most fundamental aspects of the security model implemented by SELinux. Some may infer otherwise from your document. In fact, I am not sure how you can provide integrity support without labels. AppArmor confines a process, but does not effectively confine its output files, precisely because the output files are not labeled. Other processes are free to access the unlabeled, potentially malicious output files without restriction. That depends on what you mean by integrity. It is true that AppArmor does not directly manage information flow. AppArmor assumes that if you granted write permission to /etc/resolv.conf, that you meant to do that. Whether any other process is permitted to access /etc/resolv.conf is determined by those other process's respective profiles. Integrity protection requires information flow control; you can't protect a high integrity process from being corrupted by a low integrity process if you don't control the flow of information. Plenty of attacks take the form of a untrusted process injecting data that will ultimately be used by a more trusted process with a surprising side effect. And you can't do information flow control if you can't provide global and persistent protection of the data, which requires labeling it and preserving that label for its lifetime. What AppArmor provides is a way for administrators to confine software that they have to run but do not trust. The use of pathnames means that the administrator can understand the exact meaning of the security policy, without having to do a complete labeling of the file system. The flip side of not managing information flow is that each profile is independent of every other profile. They aren't truly independent; the composition may lead to surprising results where each individual program is confined exactly as you specified, but in combination, one is able to corrupt the higher integrity subject by actions taken by the lower integrity subject. Particularly in the fun area of publically writable directories, where pathnames are largely useless as an indicator. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
In article [EMAIL PROTECTED] you wrote: Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. Hu? Even a compromised httpd (especially a compromised httpd) is bound to the app armor policies. This means it cannot (for example) write to /var/www/* - if it never needed to at normal/profiling time. Gruss Bernd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Stephen Smalley wrote: Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM Vol 16 No 10) means information flow control, which you have agreed AppArmor does not and cannot provide. Right, that's how I understand it, too. However, I think some more caveats are in order. In all honesty, I don't think SELinux solves Lampson's problem, either. It is useful to distinguish between bit-confinement (confining the flow of information, a la Lampson) vs authority-confinement (confining the flow of privileges and the ability of the untrusted app to cause side effects on the rest of the system). No Linux system provides bit-confinement, if the confined app is malicious. AppArmor does not provide bit-confinement. Neither does SELinux. SELinux can stop some kinds of accidental leakage of secrets, but it cannot prevent deliberate attempts to leak the secrets that are known to malicious apps. The reason is that, in every system under consideration, it is easy for a malicious app to leak any secrets it might have to the outside world by using covert channels (e.g., wall-banging). In practical terms, Lampson's bit-confinement problem is just not solvable. Oh well, so it goes. A good jail needs to provide authority-confinement, but thankfully, it doesn't need to provide bit-confinement. I don't know enough about AppArmor to know whether it is able to do a good job of providing authority-confinement. If it cannot, then it deserves criticism on those grounds. Often the pragmatic solution to the covert channel problem is to ensure that untrusted apps are never given access to critical secrets in the first place. They can't leak something they don't know. This solves the confidentiality problem by avoiding any attempt to tackle the unsolvable bit-confinement problem. Note that the problem of building a good jail is a little different from the information flow control problem. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 19 Apr 2007, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. Hu? Even a compromised httpd (especially a compromised httpd) is bound to the app armor policies. This means it cannot (for example) write to /var/www/* - if it never needed to at normal/profiling time. This has been addressed several times already, please read the full thread. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Crispin Cowan wrote: How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? James Morris wrote: [...] you can change the behavior of the application and then bypass policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc. [...] Just look at their code and their own description of AppArmor. My gosh, you're right. What the heck? With all due respect to the developers of AppArmor, I can't help thinking that that's pretty lame. I think this raises substantial questions about the value of AppArmor. What is the point of having a jail if it leaves gaping holes that malicious code could use to escape? And why isn't this documented clearly, with the implications fully explained? I would like to hear the AppArmor developers defend this design decision. When we developed Janus, over 10 years ago, we defended against these attack avenues and protected everything -- not just the filesystem. Systrace does the same, as does Plash. So does Consh, and MapBox, and Ostia, to name a few other examples from the research world. This is standard stuff that is well-documented in the literature, and it seems to me it is necessary before you can claim to have a useful jail. What am I missing? P.S. I think the criticisms that AppArmor is pathname-based or AppArmor doesn't do everything SELinux does or AppArmor doesn't do information flow control are weak. But the criticism that AppArmor leaves security holes that can be used to escape the jail seems like a serious criticism to me. Perhaps a change of focus is in order. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Stephen Smalley wrote: Integrity protection requires information flow control; you can't protect a high integrity process from being corrupted by a low integrity process if you don't control the flow of information. Plenty of attacks take the form of a untrusted process injecting data that will ultimately be used by a more trusted process with a surprising side effect. I don't agree with this blanket statement. In a number of cases of practical interest, useful integrity protection can be achieved without full information flow control. Suppose you have a malicious (low integrity) process A, and a target (high integrity) process B. We want to prevent A from attacking B. One way to do that is to ensure that A has no overt channel it can use to attack process B, by severely restricting A's ability to cause side effects on the rest of the world. This is often sufficient to contain the damage that A can do. Of course, if the intended functionality of the system requires A to communicate data to B, and if you don't trust B's ability to handle that data carefully enough, and if A is malicious, then you've got a serious problem. But in a number of cases (enough cases to be useful), you can provide a useful level of security without needing information flow control and without needing global, persistent labels. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 2007-04-19 at 20:08 +, David Wagner wrote: Stephen Smalley wrote: Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM Vol 16 No 10) means information flow control, which you have agreed AppArmor does not and cannot provide. Right, that's how I understand it, too. However, I think some more caveats are in order. In all honesty, I don't think SELinux solves Lampson's problem, either. It is useful to distinguish between bit-confinement (confining the flow of information, a la Lampson) vs authority-confinement (confining the flow of privileges and the ability of the untrusted app to cause side effects on the rest of the system). No Linux system provides bit-confinement, if the confined app is malicious. AppArmor does not provide bit-confinement. Neither does SELinux. SELinux can stop some kinds of accidental leakage of secrets, but it cannot prevent deliberate attempts to leak the secrets that are known to malicious apps. The reason is that, in every system under consideration, it is easy for a malicious app to leak any secrets it might have to the outside world by using covert channels (e.g., wall-banging). In practical terms, Lampson's bit-confinement problem is just not solvable. Oh well, so it goes. A good jail needs to provide authority-confinement, but thankfully, it doesn't need to provide bit-confinement. I don't know enough about AppArmor to know whether it is able to do a good job of providing authority-confinement. If it cannot, then it deserves criticism on those grounds. Often the pragmatic solution to the covert channel problem is to ensure that untrusted apps are never given access to critical secrets in the first place. They can't leak something they don't know. This solves the confidentiality problem by avoiding any attempt to tackle the unsolvable bit-confinement problem. Note that the problem of building a good jail is a little different from the information flow control problem. First, I think there is practical value in providing confidentiality control on the overt channels, even if covert channels remain. We have to start somewhere. Second, information flow is not just a confidentiality issue - see my other email. It is quite important as well for integrity, and integrity corruption in order to assume control over a privileged subject or trick it into abusing its power can be done solely via a data channel - it doesn't require explicit flow of authority. Lastly, if you want to judge AA as a jail mechanism, I think you'll find it fails there too. So where does that leave it? An easy-to-use yet inadequate solution for MAC or jail. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 19 Apr 2007, Stephen Smalley wrote: Lastly, if you want to judge AA as a jail mechanism, I think you'll find it fails there too. So where does that leave it? An easy-to-use yet inadequate solution for MAC or jail. It's not easy to use. -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Thu, 2007-04-19 at 20:54 +, David Wagner wrote: Stephen Smalley wrote: Integrity protection requires information flow control; you can't protect a high integrity process from being corrupted by a low integrity process if you don't control the flow of information. Plenty of attacks take the form of a untrusted process injecting data that will ultimately be used by a more trusted process with a surprising side effect. I don't agree with this blanket statement. In a number of cases of practical interest, useful integrity protection can be achieved without full information flow control. Suppose you have a malicious (low integrity) process A, and a target (high integrity) process B. We want to prevent A from attacking B. One way to do that is to ensure that A has no overt channel it can use to attack process B, by severely restricting A's ability to cause side effects on the rest of the world. This is often sufficient to contain the damage that A can do. If you could do that, I'd call that information flow control - I wasn't saying you had to eliminate covert channels. As you said, we don't deal with those even in SELinux. The point is that AA can't even do that, not only because it has incomplete controls but because it bases its decisions on unreliable identifiers (paths) that doesn't let it provide global and persistent protection of the data. Of course, if the intended functionality of the system requires A to communicate data to B, and if you don't trust B's ability to handle that data carefully enough, and if A is malicious, then you've got a serious problem. But in a number of cases (enough cases to be useful), you can provide a useful level of security without needing information flow control and without needing global, persistent labels. Without a reliable way of identifying the data in a system view, you can't say anything at all about the data flows. The labels provide you with a way of doing that. The paths are ambiguous, highly mutable, and often meaningless (particularly for runtime files, temporary files, etc) from a security pov. Simple example: malicious symlink attacks. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 18 Apr 2007, Crispin Cowan wrote: > James Morris wrote: > > On Tue, 17 Apr 2007, Alan Cox wrote: > > > >> I'm not sure if AppArmor can be made good security for the general case, > >> but it is a model that works in the limited http environment > >> (eg .htaccess) and is something people can play with and hack on and may > >> be possible to configure to be very secure. > >> > > Perhaps -- until your httpd is compromised via a buffer overflow or > > simply misbehaves due to a software or configuration flaw, then the > > assumptions being made about its use of pathnames and their security > > properties are out the window. > > > How is it that you think a buffer overflow in httpd could allow an > attacker to break out of an AppArmor profile? Because you can change the behavior of the application and then bypass policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc. This not even considering object aliasing (which would allow you to inappropriately access objects with full blessing of policy), as I'm assuming that the limited environment Alan is referring to entirely prevents them. Also worth noting here is that you have to consider any limited environment as enforcing security policy, and thus its configuration becomes an additional component of security policy. So, your real security policy is actually more complicated than it appears to be, is not represented completely in the policy configuration file, and must be managed disparately. And it's still only capable of controlling access to filesystem objects. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 18 Apr 2007, James Morris wrote: On Tue, 17 Apr 2007, Alan Cox wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. since AA defines a whitelist of files that httpd is allowed to access, a comprimised one may be able to mess up it's files, but it's still not going to be able to touch other files on the system. Without security labeling of the objects being accessed, you can't protect against software flaws, which has been a pretty fundamental and widely understood requirement in general computing for at least a decade. this is not true. you don't need to label all object and chunks of memory, you just need to have a way to list (and enforce) the objects and memory that the program is allowed to use. labeling them is one way of doing this, but not the only way. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 18 Apr 2007, Crispin Cowan wrote: Please explain why labels are necessary for effective confinement. Many systems besides AppArmor have used non-label schemes for effective confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS, AS400, to name just a few. This claim seems bogus. Labels may be your method of choice for confinement, but they are far from the only way. One problem with AppArmor and Janus and Systrace and everything else that relies on pathname resolution is the point where they do the pathname resolution. If you read the janus, systrace, subdomain (apparmor's predecssor?) papers, you'll see how they have to jump through hoops to handle things like symlinks, when there's no fundamental reason why they have to. If one simply worked at the FS level, all one cares about is lookup() and permission. You have a set of rules that lookup() is able to use to dynamically tag dentries and permission() then checks that tag. One doesn't jump through hoops anymore. So, while I sound like a broken record, something like a stackable file system works wonders here (I know, I implemented one). Now, stackable file systems aren't perfect here (mount point crossing, additional mounted file systems on top of the stackable file system) can cause problems, overall it seems like a cleaner solution. Another option would be if the LSM could be extended to allow a simple method of storing "private" data along with every dentry/inode (the main reason one needs a stackable file system). In this way, if the lookup() oepration was extended to be able to take a function that filled in that data and permission() was able to be extended to take a function that could use that data, one wouldn't even need a stackable file system, but one would still be operating at the simplest layer (which is the file system). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: > On Tue, 17 Apr 2007, Alan Cox wrote: > >> I'm not sure if AppArmor can be made good security for the general case, >> but it is a model that works in the limited http environment >> (eg .htaccess) and is something people can play with and hack on and may >> be possible to configure to be very secure. >> > Perhaps -- until your httpd is compromised via a buffer overflow or > simply misbehaves due to a software or configuration flaw, then the > assumptions being made about its use of pathnames and their security > properties are out the window. > How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? This is exactly what AppArmor was designed to do, and without specifics, this is just FUD. > Without security labeling of the objects being accessed, you can't protect > against software flaws, which has been a pretty fundamental and widely > understood requirement in general computing for at least a decade. > Please explain why labels are necessary for effective confinement. Many systems besides AppArmor have used non-label schemes for effective confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS, AS400, to name just a few. This claim seems bogus. Labels may be your method of choice for confinement, but they are far from the only way. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: On Tue, 17 Apr 2007, Alan Cox wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. Without security labeling of the objects being accessed, you can't protect against software flaws, which has been a pretty fundamental and widely understood requirement in general computing for at least a decade. And that's why apparmor should be implemented as a stackable file system with a container mechanism, and I implemented such a thing back in 2003, albiet mostly just proof of concept and a horribly written paper (it was my first), so never got published beyond a tech report. http://www.ncl.cs.columbia.edu/publications/cucs-005-04.pdf Basically, on disk labeling is not necessarily an easy mechanism for app armor type things as it's not easy to use and different applications have different requirements so end up w/ multiple labels attached that are difficult to understand. That's why app armor's path based rules are nice, each app has its own set of rules, and one can easily eyeball what rules apply to each app, as well as easily change it. However, since apparmor has no conception of the actual file system, so it's broken by design. If on the other hand it was implemented as a stackable file system, each fs object would be labeled. The same underlying FS could be used by multiple distinct applications w/ distinct security issues, and one could even combine it with something like unionfs to give each domain a separate writable area, avoiding the "output file issue", where output filess could be used to attack the system. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, April 18, 2007 14:15, Joshua Brindle wrote: >> Having said that, I feel a path based solution could have great >> potential >> if it could be used in conjunction with the object capability model, >> that >> I would consider a simple and practical alternative integrity model that >> does not require lables in an MLS maner, and that extends on the POLP >> concept in a way that would be largely more practical. >> > This would be combining two bad systems to get a worse one IMO. > Capability systems are inherently discretionary since propagated > capabilities must be removed at the discretion of the possessor of the > capabilities. That is assuming there is no caretaker or membrane implementation in the delegation chain, but I don't think we need to get into such details of object capabilities here. Point is there are ways to delegate revocable capabilities when using the OC model when required. > The argument that labels are not practical has yet to be shown but is > thrown around as if it is fact. Path based systems are inferior to label > based systems based if for no other reason than path based systems can't > control transient objects. With policy based type transition in SELinux > when my ssh client writes my agent socket to /tmp/ssh-xx SELinux > calculates a type transition based off my domain to label it > sysadm_ssh_t (or whatever is appropriate) whereas path based systems > can't possibly control access to these objects. The same goes for any > files written to home directories by user apps. I fully agree that path based security is inferior 'when used on its own'. >> That is, using 'thin' path based profiles would become very practical if >> all further authority can be communicated using handles in the same way >> that an open file handle can be communicated. >> > > Once again, this creates a discretionary system that would not work > without modifying every single application that uses such authority It creates a discretionary enviroment that makes it much more natural for developers to create cooperating subsystems that are designed from an least authority perspective. And it creates the means to configure the system for such programs with a minimum amounth of profile information. Next to this, but a bit more complicated, path based security could in theory be used to make required authority explicitly designated. That is calling : cp ~/foo.txt ~/bar_directory/ could ultimately explicitly transfer the user his authorities to both ~/foo.txt and ~/bar_directory/ to this instance of 'cp', but without transfering any other ambient authority. This example may be a bit out of the current range for AppArmor, but I feel it demonstrates that path based security may have potential added value in a least authority context. That is if Allice has authority to ~/, and ~/ contains ~/important.doc and allice has rw access to ~/important.doc, than ultimately invoking 'cp ~/foo.txt ~/bar_directory/' should not give the 'cp' instance the authority to read/write ~/important.doc, but invoking 'cp ~/foo.doc ~/important.doc' should. That is, if we want cp to work unmodified. > (and > trusting the code is bug free so that it does the right thing) I think the abouve shows that it actualy requeres 'less' trust in code if implemented right. > and gives > you an inflexible, decentralized, unmaintainable, unanalyzable policy > since it is distributed throughout code all over the system, you give > users no way to change the security characteristics of the system. I agree with the decentralized part, but in my view accomodating and allowing free and optionaly revocable delegation (you can always proxy anyway, so we know blocking it is misguided) makes for a much more flexible and esspecialy usable form of security. Systems designed according to POLA are definetely the most easy to do formal analysis of security properties on. I am not saying that path-based + OC would be 'better' than label based, I feel both would have their own level of granularity where they are usefull, and in some cases they could be complementary. I feel path based would be useless when possitioned purely as MAC, but when possitioned more as least authority bootstrap and designation mechanism complementary to least authority design ant usage of the OC model, I think path based may have some concrete use. sidenote: it is amusing to see that many OC advocates use many of your arguments (inflexible, unmaintainable, hard to analyze) to dismiss many label based MLS models as viable security models;-) Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 17 Apr 2007, Alan Cox wrote: > I'm not sure if AppArmor can be made good security for the general case, > but it is a model that works in the limited http environment > (eg .htaccess) and is something people can play with and hack on and may > be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. Without security labeling of the objects being accessed, you can't protect against software flaws, which has been a pretty fundamental and widely understood requirement in general computing for at least a decade. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 18 Apr 2007, David Lang wrote: > SELinux is designed to be able to make the box safe against root, AA is > designed to let the admin harden exposed apps without having to think about > the other things on the system. This is not correct. SELinux was designed as an access control framework which allows various security models to be composed in a controlled and consistent manner, covering all security-relevant interactions in the system. The type enforcement model included with it provides a means to address both integrity and confidentiality requirements. It _can_ protect you against root, if that's what you want (in fact, the Russell Coker "play box" was online for many years with a published root password), but it does not have to. Indeed, since Fedora Core 3, the default SELinux policy has been "targeted", which is aimed at confining exposed applications. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
--- Joshua Brindle <[EMAIL PROTECTED]> wrote: > Biba and BLP are only incompatible if they are using the same label, if > each object has a confidentiality and integrity label they work fine > together Joshua is correct here, although the original Biba observation was that flipping BLP upside down results in an integrity model. Trusted Irix uses (used?) both Biba and BLP. > (as well as MLS systems work in general that is). Doh! He had to get the dig in. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Rob Meijer wrote: On Tue, April 17, 2007 23:55, Karl MacMillan wrote: On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: On Mon, 16 Apr 2007, John Johansen wrote: Label-based security (exemplified by SELinux, and its predecessors in MLS systems) attaches security policy to the data. As the data flows through the system, the label sticks to the data, and so security policy with respect to this data stays intact. This is a good approach for ensuring secrecy, the kind of problem that intelligence agencies have. Labels are also a good approach for ensuring integrity, which is one of the most fundamental aspects of the security model implemented by SELinux. Some may infer otherwise from your document. Not only that, the implication that secrecy is only useful to intelligence agencies is pretty funny. Personally, I think that protecting the confidentiality of my data is important (and my bank and health care providers protecting the data they have about me). Type Enforcement was specifically designed to be able to address integrity _and_ confidentiality in a way acceptable to commercial organizations. Karl Shouldn't that be _OR_, as I have always understood confidentialy models like BLP are by their very nature incompatible with integrity models like Biba. Given this incompatibity, I think the idea that BLP style use of lables (ss/* property and the likes) is only usefull to intelligence agencies may well be correct, while usage for integrity models like Biba and CW would be much broader than that. Biba and BLP are only incompatible if they are using the same label, if each object has a confidentiality and integrity label they work fine together (as well as MLS systems work in general that is). Type enforcement, however, lets you accomplish both integrity and confidentiality (though not easily hierarchal confidentiality*). Take a mail client for example, I could argue that my mail is confidential so I label it my_mail_t and only give access to my mail client to read it and the MTA to write it. Further I limit access of my mail client to objects that can reduce its integrity such as untrusted files in /tmp, less trusted user home directories and so on. Despite AA advocate claims that info flow doesn't matter to integrity it does. I must be able to see what can write to objects that my mail client can read if I want to make any claims about its integrity. * hierarchal confidentiality is obtained with an additional BLP label that is evaluated as set of constraints over the type enforcement permissions. SELinux is extensible in this way where AA is not. A path based 'least priviledge' (POLP) solution would I think on its own address neither integity nor confidentiality, and next to this would proof to be yet an other 'fat profile' administration hell. Having said that, I feel a path based solution could have great potential if it could be used in conjunction with the object capability model, that I would consider a simple and practical alternative integrity model that does not require lables in an MLS maner, and that extends on the POLP concept in a way that would be largely more practical. This would be combining two bad systems to get a worse one IMO. Capability systems are inherently discretionary since propagated capabilities must be removed at the discretion of the possessor of the capabilities. The argument that labels are not practical has yet to be shown but is thrown around as if it is fact. Path based systems are inferior to label based systems based if for no other reason than path based systems can't control transient objects. With policy based type transition in SELinux when my ssh client writes my agent socket to /tmp/ssh-xx SELinux calculates a type transition based off my domain to label it sysadm_ssh_t (or whatever is appropriate) whereas path based systems can't possibly control access to these objects. The same goes for any files written to home directories by user apps. That is, using 'thin' path based profiles would become very practical if all further authority can be communicated using handles in the same way that an open file handle can be communicated. Once again, this creates a discretionary system that would not work without modifying every single application that uses such authority (and trusting the code is bug free so that it does the right thing) and gives you an inflexible, decentralized, unmaintainable, unanalyzable policy since it is distributed throughout code all over the system, you give users no way to change the security characteristics of the system. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
remember that the windows NT permission model is theoreticly superior to the Unix permission model. however there are far more insecure windows boxes out there then Unix boxes (even if taken as a percentage of the installed base) I don't think that anyone is claiming that AA is superior to SELinux what people are claiming is that the model AA is proposing can improve security in some cases. to use the example from this thread /etc/resolv.conf if you have a webserver that wants to do a name lookup you can do one of two things 1. in AA configure the webserver to have ro access to /etc/resolv.conf 2. in SELinux tag /etc/resolv.conf, figure out every program on the sytem that accesses it, and then tag those programs with the right permissions. SELinux is designed to be able to make the box safe against root, AA is designed to let the admin harden exposed apps without having to think about the other things on the system. allow people to use each tool for the appropriate task. David Lang On Wed, 18 Apr 2007, Rob Meijer wrote: Date: Wed, 18 Apr 2007 09:21:13 +0200 (CEST) From: Rob Meijer <[EMAIL PROTECTED]> To: Karl MacMillan <[EMAIL PROTECTED]> Cc: James Morris <[EMAIL PROTECTED]>, John Johansen <[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: AppArmor FAQ On Tue, April 17, 2007 23:55, Karl MacMillan wrote: On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: On Mon, 16 Apr 2007, John Johansen wrote: Label-based security (exemplified by SELinux, and its predecessors in MLS systems) attaches security policy to the data. As the data flows through the system, the label sticks to the data, and so security policy with respect to this data stays intact. This is a good approach for ensuring secrecy, the kind of problem that intelligence agencies have. Labels are also a good approach for ensuring integrity, which is one of the most fundamental aspects of the security model implemented by SELinux. Some may infer otherwise from your document. Not only that, the implication that secrecy is only useful to intelligence agencies is pretty funny. Personally, I think that protecting the confidentiality of my data is important (and my bank and health care providers protecting the data they have about me). Type Enforcement was specifically designed to be able to address integrity _and_ confidentiality in a way acceptable to commercial organizations. Karl Shouldn't that be _OR_, as I have always understood confidentialy models like BLP are by their very nature incompatible with integrity models like Biba. Given this incompatibity, I think the idea that BLP style use of lables (ss/* property and the likes) is only usefull to intelligence agencies may well be correct, while usage for integrity models like Biba and CW would be much broader than that. A path based 'least priviledge' (POLP) solution would I think on its own address neither integity nor confidentiality, and next to this would proof to be yet an other 'fat profile' administration hell. Having said that, I feel a path based solution could have great potential if it could be used in conjunction with the object capability model, that I would consider a simple and practical alternative integrity model that does not require lables in an MLS maner, and that extends on the POLP concept in a way that would be largely more practical. That is, using 'thin' path based profiles would become very practical if all further authority can be communicated using handles in the same way that an open file handle can be communicated. Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, April 17, 2007 23:55, Karl MacMillan wrote: > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: >> On Mon, 16 Apr 2007, John Johansen wrote: >> >> > Label-based security (exemplified by SELinux, and its predecessors in >> > MLS systems) attaches security policy to the data. As the data flows >> > through the system, the label sticks to the data, and so security >> > policy with respect to this data stays intact. This is a good approach >> > for ensuring secrecy, the kind of problem that intelligence agencies >> have. >> >> Labels are also a good approach for ensuring integrity, which is one of >> the most fundamental aspects of the security model implemented by >> SELinux. >> >> Some may infer otherwise from your document. >> > > Not only that, the implication that secrecy is only useful to > intelligence agencies is pretty funny. Personally, I think that > protecting the confidentiality of my data is important (and my bank and > health care providers protecting the data they have about me). Type > Enforcement was specifically designed to be able to address integrity > _and_ confidentiality in a way acceptable to commercial organizations. > > Karl Shouldn't that be _OR_, as I have always understood confidentialy models like BLP are by their very nature incompatible with integrity models like Biba. Given this incompatibity, I think the idea that BLP style use of lables (ss/* property and the likes) is only usefull to intelligence agencies may well be correct, while usage for integrity models like Biba and CW would be much broader than that. A path based 'least priviledge' (POLP) solution would I think on its own address neither integity nor confidentiality, and next to this would proof to be yet an other 'fat profile' administration hell. Having said that, I feel a path based solution could have great potential if it could be used in conjunction with the object capability model, that I would consider a simple and practical alternative integrity model that does not require lables in an MLS maner, and that extends on the POLP concept in a way that would be largely more practical. That is, using 'thin' path based profiles would become very practical if all further authority can be communicated using handles in the same way that an open file handle can be communicated. Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, April 17, 2007 23:55, Karl MacMillan wrote: On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: On Mon, 16 Apr 2007, John Johansen wrote: Label-based security (exemplified by SELinux, and its predecessors in MLS systems) attaches security policy to the data. As the data flows through the system, the label sticks to the data, and so security policy with respect to this data stays intact. This is a good approach for ensuring secrecy, the kind of problem that intelligence agencies have. Labels are also a good approach for ensuring integrity, which is one of the most fundamental aspects of the security model implemented by SELinux. Some may infer otherwise from your document. Not only that, the implication that secrecy is only useful to intelligence agencies is pretty funny. Personally, I think that protecting the confidentiality of my data is important (and my bank and health care providers protecting the data they have about me). Type Enforcement was specifically designed to be able to address integrity _and_ confidentiality in a way acceptable to commercial organizations. Karl Shouldn't that be _OR_, as I have always understood confidentialy models like BLP are by their very nature incompatible with integrity models like Biba. Given this incompatibity, I think the idea that BLP style use of lables (ss/* property and the likes) is only usefull to intelligence agencies may well be correct, while usage for integrity models like Biba and CW would be much broader than that. A path based 'least priviledge' (POLP) solution would I think on its own address neither integity nor confidentiality, and next to this would proof to be yet an other 'fat profile' administration hell. Having said that, I feel a path based solution could have great potential if it could be used in conjunction with the object capability model, that I would consider a simple and practical alternative integrity model that does not require lables in an MLS maner, and that extends on the POLP concept in a way that would be largely more practical. That is, using 'thin' path based profiles would become very practical if all further authority can be communicated using handles in the same way that an open file handle can be communicated. Rob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
remember that the windows NT permission model is theoreticly superior to the Unix permission model. however there are far more insecure windows boxes out there then Unix boxes (even if taken as a percentage of the installed base) I don't think that anyone is claiming that AA is superior to SELinux what people are claiming is that the model AA is proposing can improve security in some cases. to use the example from this thread /etc/resolv.conf if you have a webserver that wants to do a name lookup you can do one of two things 1. in AA configure the webserver to have ro access to /etc/resolv.conf 2. in SELinux tag /etc/resolv.conf, figure out every program on the sytem that accesses it, and then tag those programs with the right permissions. SELinux is designed to be able to make the box safe against root, AA is designed to let the admin harden exposed apps without having to think about the other things on the system. allow people to use each tool for the appropriate task. David Lang On Wed, 18 Apr 2007, Rob Meijer wrote: Date: Wed, 18 Apr 2007 09:21:13 +0200 (CEST) From: Rob Meijer [EMAIL PROTECTED] To: Karl MacMillan [EMAIL PROTECTED] Cc: James Morris [EMAIL PROTECTED], John Johansen [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: AppArmor FAQ On Tue, April 17, 2007 23:55, Karl MacMillan wrote: On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: On Mon, 16 Apr 2007, John Johansen wrote: Label-based security (exemplified by SELinux, and its predecessors in MLS systems) attaches security policy to the data. As the data flows through the system, the label sticks to the data, and so security policy with respect to this data stays intact. This is a good approach for ensuring secrecy, the kind of problem that intelligence agencies have. Labels are also a good approach for ensuring integrity, which is one of the most fundamental aspects of the security model implemented by SELinux. Some may infer otherwise from your document. Not only that, the implication that secrecy is only useful to intelligence agencies is pretty funny. Personally, I think that protecting the confidentiality of my data is important (and my bank and health care providers protecting the data they have about me). Type Enforcement was specifically designed to be able to address integrity _and_ confidentiality in a way acceptable to commercial organizations. Karl Shouldn't that be _OR_, as I have always understood confidentialy models like BLP are by their very nature incompatible with integrity models like Biba. Given this incompatibity, I think the idea that BLP style use of lables (ss/* property and the likes) is only usefull to intelligence agencies may well be correct, while usage for integrity models like Biba and CW would be much broader than that. A path based 'least priviledge' (POLP) solution would I think on its own address neither integity nor confidentiality, and next to this would proof to be yet an other 'fat profile' administration hell. Having said that, I feel a path based solution could have great potential if it could be used in conjunction with the object capability model, that I would consider a simple and practical alternative integrity model that does not require lables in an MLS maner, and that extends on the POLP concept in a way that would be largely more practical. That is, using 'thin' path based profiles would become very practical if all further authority can be communicated using handles in the same way that an open file handle can be communicated. Rob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Rob Meijer wrote: On Tue, April 17, 2007 23:55, Karl MacMillan wrote: On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: On Mon, 16 Apr 2007, John Johansen wrote: Label-based security (exemplified by SELinux, and its predecessors in MLS systems) attaches security policy to the data. As the data flows through the system, the label sticks to the data, and so security policy with respect to this data stays intact. This is a good approach for ensuring secrecy, the kind of problem that intelligence agencies have. Labels are also a good approach for ensuring integrity, which is one of the most fundamental aspects of the security model implemented by SELinux. Some may infer otherwise from your document. Not only that, the implication that secrecy is only useful to intelligence agencies is pretty funny. Personally, I think that protecting the confidentiality of my data is important (and my bank and health care providers protecting the data they have about me). Type Enforcement was specifically designed to be able to address integrity _and_ confidentiality in a way acceptable to commercial organizations. Karl Shouldn't that be _OR_, as I have always understood confidentialy models like BLP are by their very nature incompatible with integrity models like Biba. Given this incompatibity, I think the idea that BLP style use of lables (ss/* property and the likes) is only usefull to intelligence agencies may well be correct, while usage for integrity models like Biba and CW would be much broader than that. Biba and BLP are only incompatible if they are using the same label, if each object has a confidentiality and integrity label they work fine together (as well as MLS systems work in general that is). Type enforcement, however, lets you accomplish both integrity and confidentiality (though not easily hierarchal confidentiality*). Take a mail client for example, I could argue that my mail is confidential so I label it my_mail_t and only give access to my mail client to read it and the MTA to write it. Further I limit access of my mail client to objects that can reduce its integrity such as untrusted files in /tmp, less trusted user home directories and so on. Despite AA advocate claims that info flow doesn't matter to integrity it does. I must be able to see what can write to objects that my mail client can read if I want to make any claims about its integrity. * hierarchal confidentiality is obtained with an additional BLP label that is evaluated as set of constraints over the type enforcement permissions. SELinux is extensible in this way where AA is not. A path based 'least priviledge' (POLP) solution would I think on its own address neither integity nor confidentiality, and next to this would proof to be yet an other 'fat profile' administration hell. Having said that, I feel a path based solution could have great potential if it could be used in conjunction with the object capability model, that I would consider a simple and practical alternative integrity model that does not require lables in an MLS maner, and that extends on the POLP concept in a way that would be largely more practical. This would be combining two bad systems to get a worse one IMO. Capability systems are inherently discretionary since propagated capabilities must be removed at the discretion of the possessor of the capabilities. The argument that labels are not practical has yet to be shown but is thrown around as if it is fact. Path based systems are inferior to label based systems based if for no other reason than path based systems can't control transient objects. With policy based type transition in SELinux when my ssh client writes my agent socket to /tmp/ssh-xx SELinux calculates a type transition based off my domain to label it sysadm_ssh_t (or whatever is appropriate) whereas path based systems can't possibly control access to these objects. The same goes for any files written to home directories by user apps. That is, using 'thin' path based profiles would become very practical if all further authority can be communicated using handles in the same way that an open file handle can be communicated. Once again, this creates a discretionary system that would not work without modifying every single application that uses such authority (and trusting the code is bug free so that it does the right thing) and gives you an inflexible, decentralized, unmaintainable, unanalyzable policy since it is distributed throughout code all over the system, you give users no way to change the security characteristics of the system. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
--- Joshua Brindle [EMAIL PROTECTED] wrote: Biba and BLP are only incompatible if they are using the same label, if each object has a confidentiality and integrity label they work fine together Joshua is correct here, although the original Biba observation was that flipping BLP upside down results in an integrity model. Trusted Irix uses (used?) both Biba and BLP. (as well as MLS systems work in general that is). Doh! He had to get the dig in. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 18 Apr 2007, David Lang wrote: SELinux is designed to be able to make the box safe against root, AA is designed to let the admin harden exposed apps without having to think about the other things on the system. This is not correct. SELinux was designed as an access control framework which allows various security models to be composed in a controlled and consistent manner, covering all security-relevant interactions in the system. The type enforcement model included with it provides a means to address both integrity and confidentiality requirements. It _can_ protect you against root, if that's what you want (in fact, the Russell Coker play box was online for many years with a published root password), but it does not have to. Indeed, since Fedora Core 3, the default SELinux policy has been targeted, which is aimed at confining exposed applications. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 17 Apr 2007, Alan Cox wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. Without security labeling of the objects being accessed, you can't protect against software flaws, which has been a pretty fundamental and widely understood requirement in general computing for at least a decade. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, April 18, 2007 14:15, Joshua Brindle wrote: Having said that, I feel a path based solution could have great potential if it could be used in conjunction with the object capability model, that I would consider a simple and practical alternative integrity model that does not require lables in an MLS maner, and that extends on the POLP concept in a way that would be largely more practical. This would be combining two bad systems to get a worse one IMO. Capability systems are inherently discretionary since propagated capabilities must be removed at the discretion of the possessor of the capabilities. That is assuming there is no caretaker or membrane implementation in the delegation chain, but I don't think we need to get into such details of object capabilities here. Point is there are ways to delegate revocable capabilities when using the OC model when required. The argument that labels are not practical has yet to be shown but is thrown around as if it is fact. Path based systems are inferior to label based systems based if for no other reason than path based systems can't control transient objects. With policy based type transition in SELinux when my ssh client writes my agent socket to /tmp/ssh-xx SELinux calculates a type transition based off my domain to label it sysadm_ssh_t (or whatever is appropriate) whereas path based systems can't possibly control access to these objects. The same goes for any files written to home directories by user apps. I fully agree that path based security is inferior 'when used on its own'. That is, using 'thin' path based profiles would become very practical if all further authority can be communicated using handles in the same way that an open file handle can be communicated. Once again, this creates a discretionary system that would not work without modifying every single application that uses such authority It creates a discretionary enviroment that makes it much more natural for developers to create cooperating subsystems that are designed from an least authority perspective. And it creates the means to configure the system for such programs with a minimum amounth of profile information. Next to this, but a bit more complicated, path based security could in theory be used to make required authority explicitly designated. That is calling : cp ~/foo.txt ~/bar_directory/ could ultimately explicitly transfer the user his authorities to both ~/foo.txt and ~/bar_directory/ to this instance of 'cp', but without transfering any other ambient authority. This example may be a bit out of the current range for AppArmor, but I feel it demonstrates that path based security may have potential added value in a least authority context. That is if Allice has authority to ~/, and ~/ contains ~/important.doc and allice has rw access to ~/important.doc, than ultimately invoking 'cp ~/foo.txt ~/bar_directory/' should not give the 'cp' instance the authority to read/write ~/important.doc, but invoking 'cp ~/foo.doc ~/important.doc' should. That is, if we want cp to work unmodified. (and trusting the code is bug free so that it does the right thing) I think the abouve shows that it actualy requeres 'less' trust in code if implemented right. and gives you an inflexible, decentralized, unmaintainable, unanalyzable policy since it is distributed throughout code all over the system, you give users no way to change the security characteristics of the system. I agree with the decentralized part, but in my view accomodating and allowing free and optionaly revocable delegation (you can always proxy anyway, so we know blocking it is misguided) makes for a much more flexible and esspecialy usable form of security. Systems designed according to POLA are definetely the most easy to do formal analysis of security properties on. I am not saying that path-based + OC would be 'better' than label based, I feel both would have their own level of granularity where they are usefull, and in some cases they could be complementary. I feel path based would be useless when possitioned purely as MAC, but when possitioned more as least authority bootstrap and designation mechanism complementary to least authority design ant usage of the OC model, I think path based may have some concrete use. sidenote: it is amusing to see that many OC advocates use many of your arguments (inflexible, unmaintainable, hard to analyze) to dismiss many label based MLS models as viable security models;-) Rob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: On Tue, 17 Apr 2007, Alan Cox wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. Without security labeling of the objects being accessed, you can't protect against software flaws, which has been a pretty fundamental and widely understood requirement in general computing for at least a decade. And that's why apparmor should be implemented as a stackable file system with a container mechanism, and I implemented such a thing back in 2003, albiet mostly just proof of concept and a horribly written paper (it was my first), so never got published beyond a tech report. http://www.ncl.cs.columbia.edu/publications/cucs-005-04.pdf Basically, on disk labeling is not necessarily an easy mechanism for app armor type things as it's not easy to use and different applications have different requirements so end up w/ multiple labels attached that are difficult to understand. That's why app armor's path based rules are nice, each app has its own set of rules, and one can easily eyeball what rules apply to each app, as well as easily change it. However, since apparmor has no conception of the actual file system, so it's broken by design. If on the other hand it was implemented as a stackable file system, each fs object would be labeled. The same underlying FS could be used by multiple distinct applications w/ distinct security issues, and one could even combine it with something like unionfs to give each domain a separate writable area, avoiding the output file issue, where output filess could be used to attack the system. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: On Tue, 17 Apr 2007, Alan Cox wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? This is exactly what AppArmor was designed to do, and without specifics, this is just FUD. Without security labeling of the objects being accessed, you can't protect against software flaws, which has been a pretty fundamental and widely understood requirement in general computing for at least a decade. Please explain why labels are necessary for effective confinement. Many systems besides AppArmor have used non-label schemes for effective confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS, AS400, to name just a few. This claim seems bogus. Labels may be your method of choice for confinement, but they are far from the only way. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 18 Apr 2007, Crispin Cowan wrote: Please explain why labels are necessary for effective confinement. Many systems besides AppArmor have used non-label schemes for effective confinement: TRON, Janus, LIDS, Systrace, BSD Jail, EROS, PSOS, KeyOS, AS400, to name just a few. This claim seems bogus. Labels may be your method of choice for confinement, but they are far from the only way. One problem with AppArmor and Janus and Systrace and everything else that relies on pathname resolution is the point where they do the pathname resolution. If you read the janus, systrace, subdomain (apparmor's predecssor?) papers, you'll see how they have to jump through hoops to handle things like symlinks, when there's no fundamental reason why they have to. If one simply worked at the FS level, all one cares about is lookup() and permission. You have a set of rules that lookup() is able to use to dynamically tag dentries and permission() then checks that tag. One doesn't jump through hoops anymore. So, while I sound like a broken record, something like a stackable file system works wonders here (I know, I implemented one). Now, stackable file systems aren't perfect here (mount point crossing, additional mounted file systems on top of the stackable file system) can cause problems, overall it seems like a cleaner solution. Another option would be if the LSM could be extended to allow a simple method of storing private data along with every dentry/inode (the main reason one needs a stackable file system). In this way, if the lookup() oepration was extended to be able to take a function that filled in that data and permission() was able to be extended to take a function that could use that data, one wouldn't even need a stackable file system, but one would still be operating at the simplest layer (which is the file system). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 18 Apr 2007, James Morris wrote: On Tue, 17 Apr 2007, Alan Cox wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. since AA defines a whitelist of files that httpd is allowed to access, a comprimised one may be able to mess up it's files, but it's still not going to be able to touch other files on the system. Without security labeling of the objects being accessed, you can't protect against software flaws, which has been a pretty fundamental and widely understood requirement in general computing for at least a decade. this is not true. you don't need to label all object and chunks of memory, you just need to have a way to list (and enforce) the objects and memory that the program is allowed to use. labeling them is one way of doing this, but not the only way. David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 18 Apr 2007, Crispin Cowan wrote: James Morris wrote: On Tue, 17 Apr 2007, Alan Cox wrote: I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Perhaps -- until your httpd is compromised via a buffer overflow or simply misbehaves due to a software or configuration flaw, then the assumptions being made about its use of pathnames and their security properties are out the window. How is it that you think a buffer overflow in httpd could allow an attacker to break out of an AppArmor profile? Because you can change the behavior of the application and then bypass policy entirely by utilizing any mechanism other than direct filesystem access: IPC, shared memory, Unix domain sockets, local IP networking, remote networking etc. This not even considering object aliasing (which would allow you to inappropriately access objects with full blessing of policy), as I'm assuming that the limited environment Alan is referring to entirely prevents them. Also worth noting here is that you have to consider any limited environment as enforcing security policy, and thus its configuration becomes an additional component of security policy. So, your real security policy is actually more complicated than it appears to be, is not represented completely in the policy configuration file, and must be managed disparately. And it's still only capable of controlling access to filesystem objects. - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: >This is not what the discussion is about. It's about addressing the many >points in the FAQ posted here which are likely to cause misunderstandings, >and then subsequent responses of a similar nature. Thank you. Then I misunderstood, and I owe you an apology. Thank you for your patience and for correcting my mistaken impression. For what it's worth, I agreed with most or all of the comments you made in your original response to the FAQ posted here. I thought they were constructive. What got me to ranting was an email from Karl MacMillan that seemed focused more on debating the merits of AppArmor rather than on improving the FAQ. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 18 Apr 2007, David Wagner wrote: > These systems probably have different tradeoffs. Consequently, it seems > to me that arguing over whether SELinux is superior to AppArmor makes > about as much sense as arguing over whether emacs is superior to vim, > or whether Python is superior to Perl. The answer is likely to be > "it depends". This is not what the discussion is about. It's about addressing the many points in the FAQ posted here which are likely to cause misunderstandings, and then subsequent responses of a similar nature. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: >On Tue, 17 Apr 2007, David Wagner wrote: >> Maybe you'd like to confine the PHP interpreter to limit what it can do. >> That might be a good application for something like AppArmor. You don't >> need comprehensive information flow control for that kind of use, and >> it would likely just get in the way. > >SELinux can do this, it's policy-flexible. You can even simulate a >pathame-based policy language with a consequential loss of control: I have no doubt that SELinux can do that, but that has about as much relevance to my point as the price of tea in China does. I can use a screwdriver to drive in a nail into my wall, too, if I really wanted to, but that doesn't mean toolmakers should stop manufacturing hammers. My point is that there are some tasks where it's plausible that AppArmor might well be a better (easier-to-use) tool for the job. I'm inclined to suspect I might find it easier to use AppArmor for this kind of task than SELinux, and I suspect I'm not the only one. That doesn't mean that AppArmor is somehow inherently superior to SELinux, or something like that. No one is claiming that AppArmor is "a better SELinux". It solves a somewhat different problem, and has a different set of tradeoffs. It seems potentially useful. That ought to be enough. The world does not revolve around SELinux. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
James Morris wrote: >I would challenge the claim that AppArmor offers any magic bullet for >ease of use. There are, of course, no magic bullets for ease of use. I would not make such a strong claim. I simply stated that it is plausible that AppArmor might have some advantages in some deployment environments. The purpose of LSM was to enable multiple different approaches to security, so that we don't have to fight over the One True Way to do it. There might not be one best way for all situations. These systems probably have different tradeoffs. Consequently, it seems to me that arguing over whether SELinux is superior to AppArmor makes about as much sense as arguing over whether emacs is superior to vim, or whether Python is superior to Perl. The answer is likely to be "it depends". It's to be expected that SELinux developers prefer their own system over AppArmor, or that AppArmor developers prefer AppArmor to SELinux. (Have you ever seen any new parent who thinks their own baby is ugly?) SELinux developers are likely to have built a system that addresses the problems that seem important to them; other systems might set priorities differently. I think in this case the best remedy is to let many flowers bloom, and let the users decide for themselves. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 17 Apr 2007, David Wagner wrote: > Maybe you'd like to confine the PHP interpreter to limit what it can do. > That might be a good application for something like AppArmor. You don't > need comprehensive information flow control for that kind of use, and > it would likely just get in the way. SELinux can do this, it's policy-flexible. You can even simulate a pathame-based policy language with a consequential loss of control: http://seedit.sourceforge.net/ > might well use AppArmor. They solve different problems and have different > tradeoffs. There is room for more than one security tool in the world. That is not the point of this discussion, although we can at least be thankful that Linus didn't request that the networking layer be pluggable to the extent that the security layer is, otherwise we'd have a menagerie of "better" TCP stacks, TOE frameworks, STREAMS modules and whatever other fantastic ideas that people might be inclined to drag out of the kitchen sink. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 17 Apr 2007, David Wagner wrote: > be more usable than SELinux. Even if SELinux is more "complete" > than AppArmor, I might still prefer ease of use over completeness > and understandability. I would challenge the claim that AppArmor offers any magic bullet for ease of use. There are plenty of examples of people disabling it because their apps stop working: http://lists.opensuse.org/opensuse/2006-07/msg02440.html "Suddenly I have to disable AppArmor to start postfix." Sound familiar ? I'd also challenge the idea that the pathname policy scheme is easy enough for users to understand and meaningfully manage. The chief architect of the project can't explain a simple policy he used to demonstrate its simplicity: http://marc.info/?l=full-disclosure=114429157431167=2 " > but as you posted an example profile with "capability setuid", I must > admit I am curious as to why an email client needs that. Well now that is a very good question, but it has nothing to do with AppArmor. The AppArmor learning mode just records the actions that the application performs. With or without AppArmor, the Thunderbird mail client is using cap_setuid. AppArmor gives you the opportunity to *deny* that capability, so you can try blocking it and find out. But for documentation on why Thunderbird needs it, you would have to look at mozilla.org not the AppArmor pages. " What this is demonstrates is that usability has nothing to do with pathnames or labels, and that the underlying complexity of the system dominates the issue. In this case, the application needs a certain capability -- setuid, no less -- and the user doesn't understand why. At this point, AppArmor loses its claimed transparency, and the user must ultimately understand what the system is doing and why. SELinux, at the lowest level, simply exposes the complexity of the underlying security-relevant interactions of the system for the purposes of control. Usability needs to be addressed at a higher level. Something that is poorly understood is that SELinux policy was never intended to be developed by users. It's like an assembly-language; it provides an extremely low-level mechanism for controlling all security-relevant accesses in the operating system. The solution, as with programming languages (to continue the analogy), is to develop higher-level abstractions to hide the underlying complexity. Good progress has already been made in this area, and more is expected. I certainly don't think the solution is to start out by ignoring the underlying complexity. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Karl MacMillan wrote: >My private ssh keys need to be protected regardless >of the file name - it is the "bag of bits" that make it important not >the name. I think you picked a bad example. That's a confidentiality policy. AppArmor can't make any guarantees about confidentiality. Neither can SELinux. If you give a malicious app the power to read your private ssh key, it's game over, dude. (Covert channels, wall banging, and all that.) So don't do that. >Similarly, you protect the integrity of the applications that >need name resolution by ensuring that the data that they read is high >integrity. You do that by controlling data not the file name used to >access the data. That is James point - a comprehensive mechanism like >SELinux allows you to comprehensively protect the integrity of data. I think this argument just misses the point. What you want isn't what AppArmor does. Fine. Nobody is forcing you to use AppArmor. But that doesn't mean AppArmor is useless. There may be people who want what AppArmor has to provide. It sounds like you want a comprehensive information flow control system. That's not what AppArmor provides. If I understand correctly, one thing AppArmor does provide is a way to confine untrusted legacy apps in a restricted jail. That can be useful in some scenarios. Consider, for instance, a web server where untrusted users can upload PHP scripts, and you're concerned that those PHP scripts might be malicious. Maybe you'd like to confine the PHP interpreter to limit what it can do. That might be a good application for something like AppArmor. You don't need comprehensive information flow control for that kind of use, and it would likely just get in the way. Those who want a information flow control system, will probably use SELinux or something like it. Those who want what AppArmor has to offer, might well use AppArmor. They solve different problems and have different tradeoffs. There is room for more than one security tool in the world. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote: > David Safford wrote: > > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: > > > > The meaning of a file is how other processes interpret it. Until then, > /etc/resolv.conf is just a quaint bag of bits. What makes it special is > that it is what each process gets when they open the well-known > "/etc/resolv.conf". Which is why it is useful to guard which processes > can read or write to /etc/resolv.conf; the name is what makes its > content special, not the other way around. > This is not correct. My private ssh keys need to be protected regardless of the file name - it is the "bag of bits" that make it important not the name. Similarly, you protect the integrity of the applications that need name resolution by ensuring that the data that they read is high integrity. You do that by controlling data not the file name used to access the data. That is James point - a comprehensive mechanism like SELinux allows you to comprehensively protect the integrity of data. Karl > Crispin > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 15:55 -0700, Crispin Cowan wrote: > Karl MacMillan wrote: > > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: > > > >> On Mon, 16 Apr 2007, John Johansen wrote: > >> > >>> Label-based security (exemplified by SELinux, and its predecessors in > >>> MLS systems) attaches security policy to the data. As the data flows > >>> through the system, the label sticks to the data, and so security > >>> policy with respect to this data stays intact. This is a good approach > >>> for ensuring secrecy, the kind of problem that intelligence agencies have. > >>> > >> Labels are also a good approach for ensuring integrity, which is one of > >> the most fundamental aspects of the security model implemented by SELinux. > >> > >> > >> Some may infer otherwise from your document. > >> > > Not only that, the implication that secrecy is only useful to > > intelligence agencies is pretty funny. > That was not the claim. It might not have been the claim, but I certainly think it was the implication. > Rather, that intelligence agencies have a very > strong need for privacy, and will go to greater lengths to get it, > including using MLS systems. I contend that while most organizations > want privacy, they don't want it so badly that they will put up with > MLS, and so are looking for a more tolerable form of security. > Definitely - which is why SELinux is primarily about type enforcement. > This is relevant here because information flow is the main advantage of > labels over pathnames for access control. I would say that controlling information flow is _one_ of the main advantages of labels. There are others. > AppArmor does not attempt to > manage information flow, allowing it to use pathnames to achieve ease of > use. If you want information flow control, then by all means use a > label-based system. > You're trying to force a false choice between "ease of use" and "information flow control". These AppArmor / SELinux debates are irritating enough without these kinds of misleading rhetorical techniques. Karl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Karl MacMillan wrote: > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: > >> On Mon, 16 Apr 2007, John Johansen wrote: >> >>> Label-based security (exemplified by SELinux, and its predecessors in >>> MLS systems) attaches security policy to the data. As the data flows >>> through the system, the label sticks to the data, and so security >>> policy with respect to this data stays intact. This is a good approach >>> for ensuring secrecy, the kind of problem that intelligence agencies have. >>> >> Labels are also a good approach for ensuring integrity, which is one of >> the most fundamental aspects of the security model implemented by SELinux. >> >> Some may infer otherwise from your document. >> > Not only that, the implication that secrecy is only useful to > intelligence agencies is pretty funny. That was not the claim. Rather, that intelligence agencies have a very strong need for privacy, and will go to greater lengths to get it, including using MLS systems. I contend that while most organizations want privacy, they don't want it so badly that they will put up with MLS, and so are looking for a more tolerable form of security. This is relevant here because information flow is the main advantage of labels over pathnames for access control. AppArmor does not attempt to manage information flow, allowing it to use pathnames to achieve ease of use. If you want information flow control, then by all means use a label-based system. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
--- Karl MacMillan <[EMAIL PROTECTED]> wrote: > On Tue, 2007-04-17 at 13:19 -0700, Casey Schaufler wrote: > > --- Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > although this can often be done with PAM plugins, which is a standard > way > > > > to do this kind of thing in modern Unix & Linux OSs. > > > > > > PAM plugins in vi and emacs? Scary idea. > > > > > > And what do you do if someone decides to use OpenOffice to edit their > > > /etc/resolv.conf? For a lot of people that's the only text editor > > > they know. > > > > For SELinux to be effective it has to have a complete policy definition. > > This would prevent the OpenOffice access (unless OpenOffice is in the > > modify_resolv_conf_t domain) above. > > > > This, by the way, is a fundimental advantage of a path scheme over a > > label scheme in that label schemes require every object be labeled > > (it's Section 3.1.1.3 of the TCSEC if you want to look it up) while a > > path scheme (in the absences of a published requirement) only requires > > those names it cares about. SELinux in the absence of a correct and > > complete policy could be considered dangerous. > > > > This is wildly untrue (as I believe you know Casey). Is it? In an environment with automatic domain transitions and socket based administrative interfaces I can easily imagine how an incorrect or incomplete policy definition (or even one containing an ill advised regular expression in a pathname) could result in a user being able to get inappropriate service from an application. Maybe I am being silly. I am part of the generation that treats the setuid bit gingerly, and one of the people who worked to see that the POSIX capability mechanism was appropriately careful. The notion of applications flipping their security contexts about based on externally specified rules in an environment where communications with potentially privileged processes are covered by another set of those rules does not inspire confidence. I think that those rules had better be very carefully defined for them to be worthy of trust. > The effectiveness > of SELinux is certainly diminished by not confining all applications, > but that in no way makes it dangerous. It simply means that certain > aspects of the security are no longer guaranteed by the policy but > instead rely on application correctness. SELinux still offers useful > protections against a variety security threats in a targeted > configuration. OK, if it make you feel secure, that's fine. It doesn't do anything for me. > This is in contrast to a security mechanism that is path based and > doesn't control all accesses which can make _no_ guarantees about any > security goals. But ... in a targeted policy SELinux isn't controlling all accesses, either. Well, there's really no point it making further arguements. I don't expect to get through where I've failed before. And SELinux is still the best type enforcement scheme available, so if you like that sort of thing it's a fine choice. I still don't think that the arguments against path based access are particularly compelling. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
David Safford wrote: > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: > >> On Mon, 16 Apr 2007, John Johansen wrote: >> >>> Label-based security (exemplified by SELinux, and its predecessors in >>> MLS systems) attaches security policy to the data. As the data flows >>> through the system, the label sticks to the data, and so security >>> policy with respect to this data stays intact. This is a good approach >>> for ensuring secrecy, the kind of problem that intelligence agencies have. >>> >> Labels are also a good approach for ensuring integrity, which is one of >> the most fundamental aspects of the security model implemented by SELinux. >> >> Some may infer otherwise from your document. >> > In fact, I am not sure how you can provide integrity support without > labels. AppArmor confines a process, but does not effectively confine > its output files, precisely because the output files are not labeled. > Other processes are free to access the unlabeled, potentially malicious > output files without restriction. > That depends on what you mean by "integrity." It is true that AppArmor does not directly manage information flow. AppArmor assumes that if you granted write permission to /etc/resolv.conf, that you meant to do that. Whether any other process is permitted to access /etc/resolv.conf is determined by those other process's respective profiles. What AppArmor provides is a way for administrators to confine software that they have to run but do not trust. The use of pathnames means that the administrator can understand the exact meaning of the security policy, without having to do a complete labeling of the file system. The flip side of not managing information flow is that each profile is independent of every other profile. The meaning of a file is how other processes interpret it. Until then, /etc/resolv.conf is just a quaint bag of bits. What makes it special is that it is what each process gets when they open the well-known "/etc/resolv.conf". Which is why it is useful to guard which processes can read or write to /etc/resolv.conf; the name is what makes its content special, not the other way around. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com "You cannot say anything that is both simple and complete."--Crispin on Goedel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Wed, 2007-04-18 at 00:12 +0200, Andi Kleen wrote: > > The vast majority of applications are not > > modified to be SELinux aware - only a small handful of security aware > > applications are modified. > > All applications that can edit /etc/resolv.conf? That's nearly > everything. You yourself gave the example; I'm not making anything up. > No - read my other mail on this subject. > > -Andi (sensing a loop in the thread -- things that already have been > discussed come back from the dead.) > > P.S.: If you want to loop further please drop me from cc. > I might be wrong, but I think that the loop is partially coming from you not understanding how policy normally handles labeling. There is some information at http://www.nsa.gov/selinux/papers/slinux/node16.html. Karl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 20:10 +0200, Andi Kleen wrote: > On Tue, Apr 17, 2007 at 01:47:39PM -0400, James Morris wrote: > > Normal applications need zero modification under SELinux. > > > > Some applications which manage security may need to be made SELinux-aware, > > Anything that can touch /etc/resolv.conf? That's potentially a lot of binaries > if you consider anything scripts could do with it. > Certainly not - most things are handled by policy. I don't think that any applications shipped with Fedora are modified to handle resolv.conf. They are either confined and policy takes care of it or, in the case of things like vi, they are generically modified to preserve labels (and that change is partially to accommodate the targeted policy). Any application that preserves DAC mode bits should likely also preserve ACLs and SELinux labels (I guess they should potentially just preserve all xattrs - not certain). > > although this can often be done with PAM plugins, which is a standard way > > to do this kind of thing in modern Unix & Linux OSs. > > PAM plugins in vi and emacs? Scary idea. > Err, no. I don't think that is what James was suggesting. > And what do you do if someone decides to use OpenOffice to edit their > /etc/resolv.conf? For a lot of people that's the only text editor > they know. > Yeah right, I'm certain there are a lot of users (even clueless ones) that use OO for files in /etc. I assume that line wrapping alone would make this impossible and running a huge X application as root is obviously not the best idea. Actually, it seems unlikely that a clueless user would know how to run OO as root. Anyway, general concerns aside, for a targeted system this would likely just work depending on how OO saves files or whether it preserves labels. It would also be possible to create a small policy that defined a domain for OO that would allow editing resolv.conf. If you went that route the policy could set the label correctly. This is actually one of the major advantages of SELinux. You can create multiple domains for the same app that allow different actions depending on the circumstances. Karl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
> I have a different reaction. Given that the ease of use vs > completeness issues are not completely understood, I would think > it would make more sense to include both in the kernel. Wasn't that > the whole point of the LSM interface, to let competing approaches > bloom and compete on their merits? Yes and that was the decision reached last kernel summit. The remaining problem is to get AppArmor into a state ready for merging, which hopefully this review series is doing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
> The vast majority of applications are not > modified to be SELinux aware - only a small handful of security aware > applications are modified. All applications that can edit /etc/resolv.conf? That's nearly everything. You yourself gave the example; I'm not making anything up. -Andi (sensing a loop in the thread -- things that already have been discussed come back from the dead.) P.S.: If you want to loop further please drop me from cc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
> But easy to use security is probably better than complicated security > because normal people will more likely use it. Easy to use security is only better if it *works*, and preferably its excessively secure. Ineffective security is actually worse than no security. Real world examples include people using RFID badges thinking they are secure so removing the use of the conventional key in door lock and people using WEP wireless security so running no encryption or other security on their wireless. Several of whom if statements are to believed then found themselves being sued by the music industry because their IP was used for file sharing. Bad security is dangerous, really dangerous. I'm not sure if AppArmor can be made good security for the general case, but it is a model that works in the limited http environment (eg .htaccess) and is something people can play with and hack on and may be possible to configure to be very secure. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote: > On Mon, 16 Apr 2007, John Johansen wrote: > > > Label-based security (exemplified by SELinux, and its predecessors in > > MLS systems) attaches security policy to the data. As the data flows > > through the system, the label sticks to the data, and so security > > policy with respect to this data stays intact. This is a good approach > > for ensuring secrecy, the kind of problem that intelligence agencies have. > > Labels are also a good approach for ensuring integrity, which is one of > the most fundamental aspects of the security model implemented by SELinux. > > Some may infer otherwise from your document. > Not only that, the implication that secrecy is only useful to intelligence agencies is pretty funny. Personally, I think that protecting the confidentiality of my data is important (and my bank and health care providers protecting the data they have about me). Type Enforcement was specifically designed to be able to address integrity _and_ confidentiality in a way acceptable to commercial organizations. Karl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
Karl MacMillan wrote: >I don't think that the ease-of-use issue is clear cut. The hard part of >understanding both SELinux policies and AppArmor profiles is >understanding what access should be allowed. [...] >Whether the access is allowed with the SELinux or >AppArmor language seems like a small issue in comparison. Given that I >think it is better to choose the solution that is complete and capable >of meeting the most security concerns. I have a different reaction. Given that the ease of use vs completeness issues are not completely understood, I would think it would make more sense to include both in the kernel. Wasn't that the whole point of the LSM interface, to let competing approaches bloom and compete on their merits? I have to say that I'm not convinced the difference in policy languages is a small issue. I find the SELinux policy language and policy files more or less inscrutable. In comparison, from the AppArmor FAQ, I can imagine that I might be able to understand enough to hack AppArmor policies after 5 minutes of reading a man page. Whether I'm likely to know what the policy ought to be is indeed a tough question, but I can imagine that AppArmor might be more usable than SELinux. Even if SELinux is more "complete" than AppArmor, I might still prefer ease of use over completeness and understandability. And I have to say that the ability to form a mental model of how the system works and understand more or less what it is doing may be useful. I find debugging SELinux problems a bear: I often just end up disabling entire SELinux policies, or turning off SELinux, because I can't understand what it's doing. In comparison, it's plausible that it might be easier for sysadmins to understand what AppArmor is doing, since they don't have to understand labelling and hard-to-read policy files. And the increase in understandability might potentially outweigh the "completeness" issue, in some cases. Ultimately, easier to use and easier to understand tools might better solve security overall, because they are more likely to be used and to be used correctly. Bottom line: I think the comparison regarding ease of use is a bit speculative at this point, but I think there is sufficient reason for thinking that AppArmor might be a useful tool in some deployment environments. >I'd also argue that the typical interface presented to admins (which >doesn't involve writing new policies) is easier for SELinux than with >AppArmor. Most admins do fine with relabeling, changing booleans, and >running audit2allow, which is all that is needed to solve the majority >of SELinux issues. Heh. I had to chuckle at that one: it is pretty far removed from my own personal experience. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 13:19 -0700, Casey Schaufler wrote: > --- Andi Kleen <[EMAIL PROTECTED]> wrote: > > > although this can often be done with PAM plugins, which is a standard way > > > to do this kind of thing in modern Unix & Linux OSs. > > > > PAM plugins in vi and emacs? Scary idea. > > > > And what do you do if someone decides to use OpenOffice to edit their > > /etc/resolv.conf? For a lot of people that's the only text editor > > they know. > > For SELinux to be effective it has to have a complete policy definition. > This would prevent the OpenOffice access (unless OpenOffice is in the > modify_resolv_conf_t domain) above. > > This, by the way, is a fundimental advantage of a path scheme over a > label scheme in that label schemes require every object be labeled > (it's Section 3.1.1.3 of the TCSEC if you want to look it up) while a > path scheme (in the absences of a published requirement) only requires > those names it cares about. SELinux in the absence of a correct and > complete policy could be considered dangerous. > This is wildly untrue (as I believe you know Casey). The effectiveness of SELinux is certainly diminished by not confining all applications, but that in no way makes it dangerous. It simply means that certain aspects of the security are no longer guaranteed by the policy but instead rely on application correctness. SELinux still offers useful protections against a variety security threats in a targeted configuration. This is in contrast to a security mechanism that is path based and doesn't control all accesses which can make _no_ guarantees about any security goals. Karl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 2007-04-17 at 23:16 +0200, Andi Kleen wrote: > > For SELinux to be effective it has to have a complete policy definition. > > This would prevent the OpenOffice access (unless OpenOffice is in the > > modify_resolv_conf_t domain) above. > > This would mean no fully functional root user anymore. My understanding > is rather that at least in the Fedora default setup individual applications > are confined with targetted policy and root left alone because normal system > administrators get very unhappy when root becomes powerless. > > I was merely pointing out that in this setup path or namespace based access > control are much easier to fit in than label based access because they > normally > don't require changing applications. John's original document also > listed some other advantages that I don't need to repeat. > Again - this is incorrect. The vast majority of applications are not modified to be SELinux aware - only a small handful of security aware applications are modified. Most labeling is handled transparently by the policy and more could be handled by the policy if it covered all processes. > In "i don't care if it looks like Unix anymore" security setups like > you're describing that's undoubtedly different and labels might indeed > work because you forbid just anybody changing them easily. If that makes > the users happy is a different question though. I suppose it will > keep security consultants employed at least @) > Unix security is often convenient but it is clear that it is insufficient. > Arguably the preserving label issue is not unique to SELinux but > also applies to ACLs and other possible uses of EAs, but then people normally > don't need to set any ACLs on /etc/resolv.conf. > It also applies to ordinary Unix DAC. Many applications preserve mode and / or owner bits on files. Think about an editor saves to a temporary file and renames rather than directly writing the original file name. For this to work correctly the editor must explicitly preserve DAC mode bits in addition to ACLs or an SELinux label. The advantage of using a labeling scheme is, of course, that the data is always protected even in the temporary file (which might be left around if the editor crashes) while this is not true for path based security. Would DAC restrictions be acceptable if renaming a file suddenly allowed everyone to access that file? > I personally don't like either too much. Path based access control > is somewhat hackish and ugly and slow in the current implementation, > but I haven't seen an similarly easy to configure solution yet. > > plan9 like limited namespaces for individual processes initially seem > like a nice alternative, but in practice they're also too hard to use and > suffer from many of the problems the EA label approach has. > > But easy to use security is probably better than complicated security > because normal people will more likely use it. > I don't think that the ease-of-use issue is clear cut. The hard part of understanding both SELinux policies and AppArmor profiles is understanding what access should be allowed. For example, most admins are hard pressed to know whether OpenOffice should be allowed to access /dev/random or the security implications of /dev/random vs /dev/urandom. Whether the access is allowed with the SELinux or AppArmor language seems like a small issue in comparison. Given that I think it is better to choose the solution that is complete and capable of meeting the most security concerns. I'd also argue that the typical interface presented to admins (which doesn't involve writing new policies) is easier for SELinux than with AppArmor. Most admins do fine with relabeling, changing booleans, and running audit2allow, which is all that is needed to solve the majority of SELinux issues. Karl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
> For SELinux to be effective it has to have a complete policy definition. > This would prevent the OpenOffice access (unless OpenOffice is in the > modify_resolv_conf_t domain) above. This would mean no fully functional root user anymore. My understanding is rather that at least in the Fedora default setup individual applications are confined with targetted policy and root left alone because normal system administrators get very unhappy when root becomes powerless. I was merely pointing out that in this setup path or namespace based access control are much easier to fit in than label based access because they normally don't require changing applications. John's original document also listed some other advantages that I don't need to repeat. In "i don't care if it looks like Unix anymore" security setups like you're describing that's undoubtedly different and labels might indeed work because you forbid just anybody changing them easily. If that makes the users happy is a different question though. I suppose it will keep security consultants employed at least @) Arguably the preserving label issue is not unique to SELinux but also applies to ACLs and other possible uses of EAs, but then people normally don't need to set any ACLs on /etc/resolv.conf. I personally don't like either too much. Path based access control is somewhat hackish and ugly and slow in the current implementation, but I haven't seen an similarly easy to configure solution yet. plan9 like limited namespaces for individual processes initially seem like a nice alternative, but in practice they're also too hard to use and suffer from many of the problems the EA label approach has. But easy to use security is probably better than complicated security because normal people will more likely use it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 17 Apr 2007, Casey Schaufler wrote: > those names it cares about. SELinux in the absence of a correct and > complete policy could be considered dangerous. It should be noted that SELinux is only recommended as an addition to DAC, not a replacement, so that it can only further restrict existing access control. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
--- Andi Kleen <[EMAIL PROTECTED]> wrote: > On Tue, Apr 17, 2007 at 01:47:39PM -0400, James Morris wrote: > > Normal applications need zero modification under SELinux. > > > > Some applications which manage security may need to be made SELinux-aware, > > Anything that can touch /etc/resolv.conf? That's potentially a lot of > binaries > if you consider anything scripts could do with it. Well, no, you don't have to modify everything that might modify resolv.conf. You do have to define your policy so that the set of things that might modify resolv.conf is limited to the set of things that are appropriate. You also need to note that SELinux has a notion of privilege that is different from what is traditional. The ability to modify resolv.conf is determined by the domain containing it and the relationship of the domain containing the application to that domain, modified by any domain transitions that may have occured to the process prior to or during the attempted access. > > although this can often be done with PAM plugins, which is a standard way > > to do this kind of thing in modern Unix & Linux OSs. > > PAM plugins in vi and emacs? Scary idea. > > And what do you do if someone decides to use OpenOffice to edit their > /etc/resolv.conf? For a lot of people that's the only text editor > they know. For SELinux to be effective it has to have a complete policy definition. This would prevent the OpenOffice access (unless OpenOffice is in the modify_resolv_conf_t domain) above. This, by the way, is a fundimental advantage of a path scheme over a label scheme in that label schemes require every object be labeled (it's Section 3.1.1.3 of the TCSEC if you want to look it up) while a path scheme (in the absences of a published requirement) only requires those names it cares about. SELinux in the absence of a correct and complete policy could be considered dangerous. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, Apr 17, 2007 at 01:47:39PM -0400, James Morris wrote: > Normal applications need zero modification under SELinux. > > Some applications which manage security may need to be made SELinux-aware, Anything that can touch /etc/resolv.conf? That's potentially a lot of binaries if you consider anything scripts could do with it. > although this can often be done with PAM plugins, which is a standard way > to do this kind of thing in modern Unix & Linux OSs. PAM plugins in vi and emacs? Scary idea. And what do you do if someone decides to use OpenOffice to edit their /etc/resolv.conf? For a lot of people that's the only text editor they know. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AppArmor FAQ
On Tue, 17 Apr 2007, Andi Kleen wrote: > You nicely show one of the major disadvantages of the label model vs the path > model here: it requires modification of a lot of applications. This is incorrect. Normal applications need zero modification under SELinux. Some applications which manage security may need to be made SELinux-aware, although this can often be done with PAM plugins, which is a standard way to do this kind of thing in modern Unix & Linux OSs. In any case, it has never been unusual for security-critical Unix/Linux apps to be aware of extra security frameworks, and conditionally utilize things like kerberos, tcpwrappers, SSL, skey etc. Also, there's nothing inherent in pathname labeling vs. object labeling which makes one model require modification of applications more than the other. You're taking one implementation of each and extrapolating to the general case, without even taking into consideration that the modifications only refer to security-management functions. Also, in terms of implementation, these security schemes are quite different in their coverage and features, so it's an apples vs. oranges comparison anyway. Thanks, - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
