Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: Shell redirection and denials Date: Mon, 08 Oct 2007 15:08:57 -0400
/usr/sbin/my_confined_app > some_file Because the file is created by the shell, opened, and the FD handed to the application avcs can occur on read and write. Getting rid of these via policy is next to impossible - the destination file type is usually governed by the directory and we don't actually want to allow that access directly to the confined application. I'd like to see if there is some other way to get rid of these denials. I see two possible solutions:
Has either of these been investigated? 1 seems pretty simple - is there something I'm missing here (perhaps the redirection should outlast the shell lifetime?). Karl -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Shell redirection and denials Date: Tue, 09 Oct 2007 10:37:40 -0400
I believe we've told people to do (1) manually in the past (not automatically in the shell, but via the command line ala httpd -t | cat), and making that happen transparently in the shell would be a usability win. But doing it always in the shell has implications for performance and scalability; the shell then becomes a major bottleneck. The shell could conceivably do a permission check to see whether the indirection is required, but that means that user shells always need permission to compute access decisions or that the shell would fall back to always using the indirection if it lacks permission to check for that. (2) requires a kernel change, and requires care to avoid losing our ability to control propagation of access rights in accordance with policy (fundamental to MAC). I don't think you want the shell to be able to arbitrarily pass any descriptor, but being able to distinguish in policy between open (open_read, open_write) vs. transfer (transfer_read, transfer_write) vs. use (read, write) could be useful so that you can allow a process to inherit and use a descriptor without being able to directly open the file. DTOS had similar kinds of distinctions via separate permissions on holding, using, and transferring port rights. But policy would still need to allow use to all desired file types. The hardest part there is just compatibility; it would have to leverage the proposed policy.22 capability bitmap to enable the new checks. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Karl MacMillan <kmacmillan_at_mentalrootkit.com> subject: Re: Shell redirection and denials Date: Tue, 09 Oct 2007 11:04:44 -0400
Sure.
> and making that happen transparently in the shell would be a Definitely - because explaining the piping above is difficult and requires lots of changes.
> But doing it always in the shell has implications for Ok.
> (2) requires a kernel change, and requires care to avoid losing our Just what we need - more permissions! So, would 2 be useful beyond the shell? Chris / Dan, what do you think. Obviously if we can just make some changes to bash I'd rather do that. Karl -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: Shell redirection and denials Date: Tue, 09 Oct 2007 13:17:45 -0400
I can't immediately think of any examples. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Shell redirection and denials Date: Tue, 09 Oct 2007 10:23:51 -0400
Karl MacMillan wrote:
The biggest source of AVC's that I see reported is the handing off of open file descriptors. Mainly terminal descriptors. Any app that redirects STDIN/STDERR to a random file location, by opening a file and handing the descriptor, generates avc messages that cause unexpected behavior. service XYZ start >> /tmp/my.log Will almost always cause avc's and worse no output to my.log. This causes sysadmins to go nuts, and it makes no sense to them. Applications, like rpm, hal, udev, system-config-*, testing tools, any tools that restarts an init script all do this kind of thing. As we move to additional confined user domains and define additional terminal types this problem proliferates. The problem is SELinux is preventing READ/WRITE, and does not even look at Open. I understand that from a security lock down point of view this is a big security consideration. But I believe most sysadmins would want to prevent their locked down domain to OPEN files in random location, but if the domains, are handed an OPEN file descriptor from another process then they should be allowed to READ/WRITE to that OPEN Descriptor no matter where it is. So a confined domain could talk to the terminals that were handed to it but could not open random other terminals. This is by far the biggest source of dontaudit's allowed in the policy sources and ends up preventing us from seeing real potential subversions, where a confined app actually tries to open and talk to random terminals or the console. Another side effect I often see is that apps tend to do a getcwd when they start. I do not know if this is a standard C/libc activity the way apps are coded or maybe something about the way bash is coded, but this ends up generating lots of AVC messages. If you look at the confined domains, almost all of them have a dontaudit $1 sysadm_home_dir_t:dir search_dir_perms; Because any sysadm who "su -" ends up in the /root homedir and if he does a service APP restart. That APP ends up generating and AVC. I happened to be sitting in a unconfined_tmp_t directory today, when I started vpnc and boom, setroubleshoot is telling me vpnc_t tried to read unconfined_tmp_t.
-----BEGIN PGP SIGNATURE-----
iD8DBQFHC473rlYvE4MpobMRAq2sAKCl5+icAs3Yz42TeEOJrYdmChsZVQCg3tZi
o3ppR6kJaECaGU+sIVifvCE=
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Shell redirection and denials Date: Tue, 09 Oct 2007 12:55:13 -0400
I understand the motivation, but merely dropping checks entirely on inheritance and transfer of descriptors means that we have no control over the propagation of access rights, which is important for confining malicious and flawed programs. Splitting the permissions such that we check one set of permissions (e.g. open_read, open_write) at open-time and a different set of permissions on transfer and/or use (read, write) would allow the policy writer to allow or dontaudit only the latter while denying w/audit the former. If we wanted to specifically control the ability to give a descriptor to another task (vs. the ability to receive/inherit/use it), we'd need another hook, as we currently only hook the receive side. Then you could have distinct transfer_read, transfer_write permissions governing who could propagate a descriptor separate from read, write permissions governing who could inherit/receive/use it.
> Another side effect I often see is that apps tend to do a getcwd when That's a different issue - it isn't an operation on an open file descriptor, and we can't distinguish it from any other lookup at least presently. Actually though sys_getcwd() shouldn't trigger a permission check at all. Traditional userland getcwd() would need to search the directory. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Kroum Antov <kroum_at_voicecho.com> subject: Re: Shell redirection and denials Date: Wed, 10 Oct 2007 00:10:51 -0700
Introducing transfer_read and transfer_write permissions will do the work too but in my opinion introduces unnecessary complexity to an already complex system. SElinux has potential beyond the standard security control but these AVC denials for file descriptors and ports transfers are greatly limiting the SELinux usability. I surely would like to see this issue addressed soon.
Kroum Antov
> On Tue, 2007-10-09 at 10:23 -0400, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Karl MacMillan wrote: >> > One of Dan's constant sources of avcs is something like: >> > >> > /usr/sbin/my_confined_app > some_file >> > >> > Because the file is created by the shell, opened, and the FD handed to >> > the application avcs can occur on read and write. >> > >> > Getting rid of these via policy is next to impossible - the destination >> > file type is usually governed by the directory and we don't actually >> > want to allow that access directly to the confined application. I'd >> > like >> > to see if there is some other way to get rid of these denials. >> > >> > I see two possible solutions: >> > >> > 1) Make the shell create and pass a descriptor to a pipe to the >> > application - the shell itself would read / write to the file. This >> > seems, to me, to more accurately reflect how we want to enforce the >> > permissions. >> > >> > 2) Allow applications to confer access by passing the file descriptor >> > (more like capabilities). This more closely matches how Unix actually >> > works and, of course, is a huge source of vulnerabilities. Allowing >> > this >> > type of scheme just for shells might not be that bad. >> > >> > Has either of these been investigated? 1 seems pretty simple - is there >> > something I'm missing here (perhaps the redirection should outlast the >> > shell lifetime?). >> > >> > Karl >> > >> >> The biggest source of AVC's that I see reported is the handing off of >> open file descriptors. Mainly terminal descriptors. Any app that >> redirects STDIN/STDERR to a random file location, by opening a file and >> handing the descriptor, generates avc messages that cause unexpected >> behavior. >> >> service XYZ start >> /tmp/my.log >> >> Will almost always cause avc's and worse no output to my.log. This >> causes sysadmins to go nuts, and it makes no sense to them. >> >> Applications, like rpm, hal, udev, system-config-*, testing tools, any >> tools that restarts an init script all do this kind of thing. As we >> move to additional confined user domains and define additional terminal >> types this problem proliferates. >> >> The problem is SELinux is preventing READ/WRITE, and does not even look >> at Open. I understand that from a security lock down point of view this >> is a big security consideration. But I believe most sysadmins would >> want to prevent their locked down domain to OPEN files in random >> location, but if the domains, are handed an OPEN file descriptor from >> another process then they should be allowed to READ/WRITE to that OPEN >> Descriptor no matter where it is. >> >> So a confined domain could talk to the terminals that were handed to it >> but could not open random other terminals. >> >> This is by far the biggest source of dontaudit's allowed in the policy >> sources and ends up preventing us from seeing real potential >> subversions, where a confined app actually tries to open and talk to >> random terminals or the console. > > I understand the motivation, but merely dropping checks entirely on > inheritance and transfer of descriptors means that we have no control > over the propagation of access rights, which is important for confining > malicious and flawed programs. > > Splitting the permissions such that we check one set of permissions > (e.g. open_read, open_write) at open-time and a different set of > permissions on transfer and/or use (read, write) would allow the policy > writer to allow or dontaudit only the latter while denying w/audit the > former. > > If we wanted to specifically control the ability to give a descriptor to > another task (vs. the ability to receive/inherit/use it), we'd need > another hook, as we currently only hook the receive side. Then you > could have distinct transfer_read, transfer_write permissions governing > who could propagate a descriptor separate from read, write permissions > governing who could inherit/receive/use it. > >> Another side effect I often see is that apps tend to do a getcwd when >> they start. I do not know if this is a standard C/libc activity the way >> apps are coded or maybe something about the way bash is coded, but this >> ends up generating lots of AVC messages. >> >> If you look at the confined domains, almost all of them have a >> dontaudit $1 sysadm_home_dir_t:dir search_dir_perms; >> >> Because any sysadm who "su -" ends up in the /root homedir and if he >> does a service APP restart. That APP ends up generating and AVC. >> >> I happened to be sitting in a unconfined_tmp_t directory today, when I >> started vpnc and boom, setroubleshoot is telling me vpnc_t tried to read >> unconfined_tmp_t. > > That's a different issue - it isn't an operation on an open file > descriptor, and we can't distinguish it from any other lookup at least > presently. Actually though sys_getcwd() shouldn't trigger a permission > check at all. Traditional userland getcwd() would need to search the > directory. > > -- > Stephen Smalley > National Security Agency > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov > with > the words "unsubscribe selinux" without quotes as the message. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Shell redirection and denials Date: Wed, 10 Oct 2007 08:00:16 -0400
Not if you want to be able to claim that the system enforces mandatory access control. The ability to leak a descriptor at will (unwittingly or maliciously) to an unauthorized entity violates the principles of mandatory access control. And SELinux controls on descriptor inheritance have caught any number of unwitting leaks of descriptors by programs.
> Introducing transfer_read and transfer_write permissions will do the work Splitting the permissions to allow distinctions to be made is ok, but entirely dropping the ability to control propagation of access rights is not. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: Shell redirection and denials Date: Wed, 10 Oct 2007 12:04:36 -0400
Stephen Smalley wrote: > On Wed, 2007-10-10 at 00:10 -0700, Kroum Antov wrote: >> Dan's suggestion for dropping checks entirely on inheritance and transfer of >> descriptors and do check for OPEN instead >> seems to be solid and simple solution. >> I don't see any potential security danger in doing this. Once an application >> has the proper rights on a descriptor it can do anything with it anyway. By >> passing the descriptor to other applications and allowing them to work with >> this descriptor without problems there is No security issue with this. >> Controlling the Open of the confined applications is sufficient in my >> opinion. > > Not if you want to be able to claim that the system enforces mandatory > access control. The ability to leak a descriptor at will (unwittingly > or maliciously) to an unauthorized entity violates the principles of > mandatory access control. And SELinux controls on descriptor > inheritance have caught any number of unwitting leaks of descriptors by > programs. > >> Introducing transfer_read and transfer_write permissions will do the work >> too but in my opinion introduces unnecessary complexity to an already >> complex system. >> >> SElinux has potential beyond the standard security control but these AVC >> denials for file descriptors and ports transfers are greatly limiting the >> SELinux usability. >> >> I surely would like to see this issue addressed soon. > > Splitting the permissions to allow distinctions to be made is ok, but > entirely dropping the ability to control propagation of access rights is > not. > I agree, but we can also use some common sense, there are levels of paranoia that differ depending on the context. Allowing a confined domain read/write/use any FD that is handed to them that is connected to a terminal, logfile, tmpfile, and not allowing them to open a connection to a terminal, tmpfile, logfile is a big step forward. Perhaps also allowing them to talk to fifo_file file owned by user but not open one. We can also allow the addition of booleans or changes in policy. Not ok for MLS but ok for Targeted.
-----BEGIN PGP SIGNATURE-----
iD8DBQFHDPgUrlYvE4MpobMRAhTrAJ40w4lHmvXyUYhTNaF9o6DRG+KHDQCfYZUS
Nng/pXmaQK/JmGotQ6jFif0=
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: Shell redirection and denials Date: Wed, 10 Oct 2007 12:18:52 -0400
As far as the kernel mechanism goes, it is just a matter of changing the open-time checks (selinux_inode_permission) to use a different set of permissions than the inherit/transfer/use checks (flush_unauthorized_files, selinux_file_receive, selinux_file_permission). Then you can deny open but allow the rest for whatever file types and classes you want. That's easy to implement (kernel-side, policy will take more work), but will require using something like Paul Moore's capability bitmap to avoid compatibility breakage.
> We can also allow the addition of booleans or changes in policy. Not ok -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |