Shell redirection and denials

Shell redirection and denials

[Karl MacMillan]

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


--
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.

Re: Shell redirection and denials

[Daniel J Walsh]

-----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.



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-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHC473rlYvE4MpobMRAq2sAKCl5+icAs3Yz42TeEOJrYdmChsZVQCg3tZi
o3ppR6kJaECaGU+sIVifvCE=
=PNLZ
-----END PGP SIGNATURE-----

--
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.

Re: Shell redirection and denials

[Stephen Smalley]

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.

Re: Shell redirection and denials

[Kroum Antov]

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.

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
VoicEcho LLC



----- Original Message ----- 
From: "Stephen Smalley" <sds@tycho.nsa.gov>
To: "Daniel J Walsh" <dwalsh@redhat.com>
Cc: "Karl MacMillan" <kmacmillan@mentalrootkit.com>; "SE Linux" 
<selinux@tycho.nsa.gov>; "James Morris" <jmorris@namei.org>; "Eric Paris" 
<eparis@parisplace.org>
Sent: Tuesday, October 09, 2007 9:55 AM
Subject: Re: Shell redirection and denials


> 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.

Re: Shell redirection and denials

[Stephen Smalley]

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.

-- 
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.

Re: Shell redirection and denials

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHDPgUrlYvE4MpobMRAhTrAJ40w4lHmvXyUYhTNaF9o6DRG+KHDQCfYZUS
Nng/pXmaQK/JmGotQ6jFif0=
=9oR2
-----END PGP SIGNATURE-----

--
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.

Re: Shell redirection and denials

[Stephen Smalley]

On Wed, 2007-10-10 at 12:04 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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.

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
> for MLS but ok for Targeted.

-- 
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.

Re: Shell redirection and denials

[Stephen Smalley]

On Mon, 2007-10-08 at 15:08 -0400, 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?).

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.

Re: Shell redirection and denials

[Karl MacMillan]

On Tue, 2007-10-09 at 10:37 -0400, Stephen Smalley wrote:
> On Mon, 2007-10-08 at 15:08 -0400, 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?).
> 
> 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),

Sure.

>  and making that happen transparently in the shell would be a
> usability win.

Definitely - because explaining the piping above is difficult and
requires lots of changes.

>   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.
> 

Ok.

> (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.
> 

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.

Re: Shell redirection and denials

[Christopher J. PeBenito]

On Tue, 2007-10-09 at 11:04 -0400, Karl MacMillan wrote:
> On Tue, 2007-10-09 at 10:37 -0400, Stephen Smalley wrote:
> > On Mon, 2007-10-08 at 15:08 -0400, 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:
[...]
> > > 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.
[...]
> > (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.
> > 
> 
> 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.

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.