labeling of compilers etc

labeling of compilers etc

[Russell Coker]

In many discussions about hardening systems the idea is suggested that 
machines should not have compilers unless they are development machines.

It would not be difficult to label compilers as compiler_exec_t and only 
permit user domains the ability to execute files of such type (daemons don't 
need to compile software).  What do you think of this idea?  Maybe we would 
want to have a more generic type such as devel_exec_t and label programs such 
as gdb with it as well.

Also interpreters could be modified to provide similar benefits.  Currently 
many (most?) shell interpreters try to detect and prevent setuid operation 
with code roughly equivalent to if(getuid() != geteuid()) seteuid(getuid).  
Bash currently has such code (just done a quick test) and other shells had 
such cost in place last time I tested them.  I believe that this establishes 
a precedent for shell interpreters to check for and prevent insecure modes of 
operation.

A logical extension of this precedent to SE Linux would be to have it check 
the type of a file to be executed and confirm that the current domain is 
permitted to execute scripts of the type in question, for a regular file it 
would get the context (after opening it) and ask SE Linux whether the current 
context has execute access for the file class.  For a character device node 
(IE stdin but let's not assume that's the only device to be used) it would 
check for execute access of class chr_file for the context in question.  Does 
it even make sense to execute a block device node as a shell script?

In some mailing lists related to SE Linux it's been mentioned that people 
desire these features.  I believe that I have come up with a reasonable 
design to solve the problems in question.  If it's considered worth-while 
then I'm willing to write a policy patch for the first one and a bash patch 
for the second one.

Also it should be noted that if the perl interpreter is setuid then it'll 
happily do things as the EUID, this means that we have no good precedent to 
rely on in this case.  This doesn't stop us, just means that the chance of 
getting code accepted upstream is dramatically reduced.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: labeling of compilers etc

[Steve G]

>If it's considered worth-while then I'm willing to write a policy patch for >the
first one and a bash patch for the second one.

A setuid shell script is an extremely bad idea. I think bash refuses to run them.
Is it really necessary to add a SE Linux patch to bash when it already refuses to
do this?

-Steve

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: labeling of compilers etc

[Russell Coker]

On Monday 30 January 2006 00:33, Steve G <linux_4ever@yahoo.com> wrote:
> >If it's considered worth-while then I'm willing to write a policy patch
> > for the first one and a bash patch for the second one.
>
> A setuid shell script is an extremely bad idea.

My message did not reference setuid shell scripts.

> I think bash refuses to run them.

bash will execute a shell script that is setuid, but no setuid type results 
take place.  To have a setuid script actually give a setuid result you would 
need a setuid shell interpreter that does special stuff.  The perl-suidperl 
package in Fedora has an example of how to do this.  It would be easy to 
write a similar program to allow setuid bash scripts, of course there would 
be the same security issues as setuid perl (which I believe has a bad 
security history).

One thing to note is that domain_auto_trans() rules apply to shell scripts.  
The SE Linux equivalent of setuid shell scripts is quite possible (with all 
the sym-link race conditions that involves - suidperl has special code to fix 
such race conditions that we need in bash to do such things safely).

If we are going to permit a domain_auto_trans($1, $2, $3) with a shell script 
having the type $2 then we could make it a requirement to also have the rule 
domain_trans($1, shell_exec_t, $3) and have this enforced by the shell.

> Is it really necessary to add a SE Linux patch to bash when it 
> already refuses to do this?

If we want to provide the SE Linux specific functionality (which was requested 
by many people and which is conceptually similar to some kernel security 
modules in some of the BSD Unix systems) as described in my previous message 
then we need a patch as described in my previous message.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: labeling of compilers etc

[Lorenzo Hernández García-Hierro]

[-- Attachment #1: Type: text/plain, Size: 4064 bytes --]

On dom, 2006-01-29 at 11:56 +1100, Russell Coker wrote:
> In many discussions about hardening systems the idea is suggested that 
> machines should not have compilers unless they are development machines.
> 
> It would not be difficult to label compilers as compiler_exec_t and only 
> permit user domains the ability to execute files of such type (daemons don't 
> need to compile software).  What do you think of this idea?  Maybe we would 
> want to have a more generic type such as devel_exec_t and label programs such 
> as gdb with it as well.

It's definitely a good idea to keep daemon-related users away of using
compilers and debuggers. Current behavior of web application worms is
related to the usage of 'wget' or other tools to get either a binary or
a source file.

Access to those resources should be limited as well.

> Also interpreters could be modified to provide similar benefits.  Currently 
> many (most?) shell interpreters try to detect and prevent setuid operation 
> with code roughly equivalent to if(getuid() != geteuid()) seteuid(getuid).  
> Bash currently has such code (just done a quick test) and other shells had 
> such cost in place last time I tested them.  I believe that this establishes 
> a precedent for shell interpreters to check for and prevent insecure modes of 
> operation.

That's TPE after all. Interpreters shouldn't load files from untrusted
sources: user home directories (although this would need exceptions),
world writable directories, etc.

> A logical extension of this precedent to SE Linux would be to have it check 
> the type of a file to be executed and confirm that the current domain is 
> permitted to execute scripts of the type in question, for a regular file it 
> would get the context (after opening it) and ask SE Linux whether the current 
> context has execute access for the file class.  For a character device node 
> (IE stdin but let's not assume that's the only device to be used) it would 
> check for execute access of class chr_file for the context in question.  Does 
> it even make sense to execute a block device node as a shell script?
> In some mailing lists related to SE Linux it's been mentioned that people 
> desire these features.  I believe that I have come up with a reasonable 
> design to solve the problems in question.  If it's considered worth-while 
> then I'm willing to write a policy patch for the first one and a bash patch 
> for the second one.

I would like to help with this, although the scope is a bit more complex
than it seems. The operations that can be done by the interpreters
should be limited, not only the instructions that can be loaded from a
file. In other words, flawed interpreters can be forced to perform
potentially harmful operations.

For example, binary format parsers: archive format related tools: RAR,
tar, bzip2; binary load related tools: binutils and readelf (the kernel
itself...), image processing related tools (there has been work on this
from someone else here, Colin's IMSEP?), etc.

I'm aware of some issues affecting interpreters related to binary
formats that aren't known yet, and SELinux is for sure the way to stop
them, since some of the tools that can really do an outstanding job on
this field (as in auditing work), have been prepared so anything found
before release date stays 0-day ;).

> Also it should be noted that if the perl interpreter is setuid then it'll 
> happily do things as the EUID, this means that we have no good precedent to 
> rely on in this case.  This doesn't stop us, just means that the chance of 
> getting code accepted upstream is dramatically reduced.

I think that getting code accepted by upstream maintainers isn't
mandatory. Things could get worked out later, and changes shouldn't be
made available by default (ie. we can either compile it with support for
the measures or not).

Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo@gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: labeling of compilers etc

[Russell Coker]

On Monday 30 January 2006 09:08, Lorenzo Hernández García-Hierro 
<lorenzo@gnu.org> wrote:
> It's definitely a good idea to keep daemon-related users away of using
> compilers and debuggers. Current behavior of web application worms is
> related to the usage of 'wget' or other tools to get either a binary or
> a source file.
>
> Access to those resources should be limited as well.

Limiting access to wget would also imply doing the same to lynx, links, ftp, 
ncftp, netcat, and many others.  I hadn't been planning to do that, but it 
makes sense (certainly provides a much greater benefit than ls_exec_t or the 
bin_t vs sbin_t distinction).

> > Also interpreters could be modified to provide similar benefits. 
> > Currently many (most?) shell interpreters try to detect and prevent
> > setuid operation with code roughly equivalent to if(getuid() !=
> > geteuid()) seteuid(getuid). Bash currently has such code (just done a
> > quick test) and other shells had such cost in place last time I tested
> > them.  I believe that this establishes a precedent for shell interpreters
> > to check for and prevent insecure modes of operation.
>
> That's TPE after all. Interpreters shouldn't load files from untrusted
> sources: user home directories (although this would need exceptions),
> world writable directories, etc.

If Alice can write to data that user Bob executes then that's a definite 
instance of files loaded from an untrusted source.  But if Alice writes files 
in her own context then that's usually considered regular use of the system.

Unix systems are more designed for regular users where you need to write to 
your .bashrc etc than for daemon users where writing to such files is at best 
unnecessary and at worst a major security problem.

> I would like to help with this, although the scope is a bit more complex
> than it seems. The operations that can be done by the interpreters
> should be limited, not only the instructions that can be loaded from a
> file. In other words, flawed interpreters can be forced to perform
> potentially harmful operations.

If the interpreter refuses to read instructions from stdin, from a pipe, or 
from a file of a type that can be written then shouldn't it be safe?

Of course there will be a bit of coding involved in checking the "." or 
"source" operator, the .login type files, and every other situation where an 
interpreter may read instructions.

> For example, binary format parsers: archive format related tools: RAR,
> tar, bzip2; binary load related tools: binutils and readelf (the kernel
> itself...), image processing related tools (there has been work on this
> from someone else here, Colin's IMSEP?), etc.

binutils would be devel_exec_t under the scheme I outlined previously.

What do you consider to be the issues relating to tar etc?

> > Also it should be noted that if the perl interpreter is setuid then it'll
> > happily do things as the EUID, this means that we have no good precedent
> > to rely on in this case.  This doesn't stop us, just means that the
> > chance of getting code accepted upstream is dramatically reduced.
>
> I think that getting code accepted by upstream maintainers isn't
> mandatory. Things could get worked out later, and changes shouldn't be
> made available by default (ie. we can either compile it with support for
> the measures or not).

Sure we can do things without support from upstream.  But it's a lot easier if 
we do have such support.  They can often suggest better ways to achieve our 
goals, and if they merge our patches into the main tree then it'll save us a 
lot of maintenance work in the long term.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: labeling of compilers etc

[Lorenzo Hernández García-Hierro]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On lun, 2006-01-30 at 10:03 +1100, Russell Coker wrote:
> Limiting access to wget would also imply doing the same to lynx, links, ftp, 
> ncftp, netcat, and many others.

Right.

> What do you consider to be the issues relating to tar etc?

I'm generally talking about binfmt/file parsing risks. 'tar' shouldn't
be able to do anything more than what it has been designed for.

Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo@gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: labeling of compilers etc

[Russell Coker]

On Monday 30 January 2006 11:26, Lorenzo Hernández García-Hierro 
<lorenzo@gnu.org> wrote:
> > What do you consider to be the issues relating to tar etc?
>
> I'm generally talking about binfmt/file parsing risks. 'tar' shouldn't
> be able to do anything more than what it has been designed for.

When run by a user tar needs to be able to create and overwrite files in that 
user's home directory.

The same user needs to be able to edit their .bashrc file etc.

To achieve both these goals while not allowing tar to write to .bashrc (which 
seems to fit "anything more than what it has been designed for") then 
the .bashrc file would need a different type.  This would involve lots of 
extra pain and therefore is not something that I think is viable at this 
time.

While changes to shell interpreters will require some coding work, I think 
that they will be much more acceptable to the users and therefore more 
acceptable into mainstream distributions such as Fedora Core, Red Hat 
Enterprise Linux, and Debian.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: labeling of compilers etc

[Stephen Smalley]

On Sun, 2006-01-29 at 11:56 +1100, Russell Coker wrote:
> In many discussions about hardening systems the idea is suggested that 
> machines should not have compilers unless they are development machines.
> 
> It would not be difficult to label compilers as compiler_exec_t and only 
> permit user domains the ability to execute files of such type (daemons don't 
> need to compile software).  What do you think of this idea?  Maybe we would 
> want to have a more generic type such as devel_exec_t and label programs such 
> as gdb with it as well.

The other option would be to instead only label files that you want to
be executable by such users with a distinct type (e.g.
user_executable_t), and then remove access to the other types (bin_t,
sbin_t, *_exec_t, ...) from the user domains for such systems.  I
suspect that in such environments, you not only want to prohibit use of
the development toolchain, but also want to limit users to only
executing a specific set of approved programs.

> Also interpreters could be modified to provide similar benefits.  Currently 
> many (most?) shell interpreters try to detect and prevent setuid operation 
> with code roughly equivalent to if(getuid() != geteuid()) seteuid(getuid).  
> Bash currently has such code (just done a quick test) and other shells had 
> such cost in place last time I tested them.  I believe that this establishes 
> a precedent for shell interpreters to check for and prevent insecure modes of 
> operation.
> 
> A logical extension of this precedent to SE Linux would be to have it check 
> the type of a file to be executed and confirm that the current domain is 
> permitted to execute scripts of the type in question, for a regular file it 
> would get the context (after opening it) and ask SE Linux whether the current 
> context has execute access for the file class.

This is a policy issue at the kernel level, not something the shell
should get involved in.  If the policy author has decided to allow a
domain transition and to mark a script with an entrypoint type, then
that is their choice, and it may be a perfectly valid choice in specific
cases (e.g. shedding of permissions where subversion by the caller would
not yield any security risk since the caller already has more
permissions than the callee or where the caller is trusted).  The
current policy does make use of such transitions (e.g. init_t ->
initrc_t), so we certainly do not want to break them.  It would make
sense for a policy lint/checker tool (like sechecker) to check the
file_contexts configuration or filesystem state for scripts that have
entrypoint types and report on such transitions, flagging in particular
cases where the calling domain is not already more privileged than the
new domain for review by the policy writer or admin.  But I don't think
we want a blanket prohibition enforced by the shell.

>   For a character device node 
> (IE stdin but let's not assume that's the only device to be used) it would 
> check for execute access of class chr_file for the context in question.  Does 
> it even make sense to execute a block device node as a shell script?

No.  open_exec() in the kernel rejects anything that isn't a regular
file.

> In some mailing lists related to SE Linux it's been mentioned that people 
> desire these features.  I believe that I have come up with a reasonable 
> design to solve the problems in question.  If it's considered worth-while 
> then I'm willing to write a policy patch for the first one and a bash patch 
> for the second one.
> 
> Also it should be noted that if the perl interpreter is setuid then it'll 
> happily do things as the EUID, this means that we have no good precedent to 
> rely on in this case.  This doesn't stop us, just means that the chance of 
> getting code accepted upstream is dramatically reduced.

-- 
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: labeling of compilers etc

[Russell Coker]

On Tuesday 31 January 2006 01:29, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Sun, 2006-01-29 at 11:56 +1100, Russell Coker wrote:
> > In many discussions about hardening systems the idea is suggested that
> > machines should not have compilers unless they are development machines.
> >
> > It would not be difficult to label compilers as compiler_exec_t and only
> > permit user domains the ability to execute files of such type (daemons
> > don't need to compile software).  What do you think of this idea?  Maybe
> > we would want to have a more generic type such as devel_exec_t and label
> > programs such as gdb with it as well.
>
> The other option would be to instead only label files that you want to
> be executable by such users with a distinct type (e.g.
> user_executable_t), and then remove access to the other types (bin_t,
> sbin_t, *_exec_t, ...) from the user domains for such systems.  I
> suspect that in such environments, you not only want to prohibit use of
> the development toolchain, but also want to limit users to only
> executing a specific set of approved programs.

That sounds reasonable and fits with the SE Linux design philosophy of 
default-deny.  Of course it'll be more fiddly to get it going acceptably.

> > Also interpreters could be modified to provide similar benefits. 
> > Currently many (most?) shell interpreters try to detect and prevent
> > setuid operation with code roughly equivalent to if(getuid() !=
> > geteuid()) seteuid(getuid). Bash currently has such code (just done a
> > quick test) and other shells had such cost in place last time I tested
> > them.  I believe that this establishes a precedent for shell interpreters
> > to check for and prevent insecure modes of operation.
> >
> > A logical extension of this precedent to SE Linux would be to have it
> > check the type of a file to be executed and confirm that the current
> > domain is permitted to execute scripts of the type in question, for a
> > regular file it would get the context (after opening it) and ask SE Linux
> > whether the current context has execute access for the file class.
>
> This is a policy issue at the kernel level, not something the shell
> should get involved in.

If the shell can read two files but should only "execute" one of them then 
it's something that can only be enforced by the shell itself.

> If the policy author has decided to allow a 
> domain transition and to mark a script with an entrypoint type, then
> that is their choice,

However it may not be their choice!  At any time a new version of some 
software could replace an executable with a shell script.

> and it may be a perfectly valid choice in specific 
> cases (e.g. shedding of permissions where subversion by the caller would
> not yield any security risk since the caller already has more
> permissions than the callee or where the caller is trusted).

True.  The case of scripts escalating permissions is the one we are concerned 
with.

> The 
> current policy does make use of such transitions (e.g. init_t ->
> initrc_t), so we certainly do not want to break them.

Naturally we would not break them.  My proposal would still support such 
things with a little extra policy.

Below the line "domain_auto_trans(init_t,initrc_exec_t,initrc_t)" we would 
merely have to add "domain_trans(init_t, shell_exec_t, initrc_t)".  The 
policy changes would be introduced before the changes to shells so no 
breakage would occur.

> It would make 
> sense for a policy lint/checker tool (like sechecker) to check the
> file_contexts configuration or filesystem state for scripts that have
> entrypoint types and report on such transitions, flagging in particular
> cases where the calling domain is not already more privileged than the
> new domain for review by the policy writer or admin.  But I don't think
> we want a blanket prohibition enforced by the shell.

I did not suggest a blanket prohibition, but merely a prohibition controlled 
by policy.  The number of instances where you really want to have a 
domain_auto_trans() based on a shell script is very small so this should not 
be difficult (absolutely no work at all when compared to the C coding needed 
to get the shells all working with it).

> >   For a character device node
> > (IE stdin but let's not assume that's the only device to be used) it
> > would check for execute access of class chr_file for the context in
> > question.  Does it even make sense to execute a block device node as a
> > shell script?
>
> No.  open_exec() in the kernel rejects anything that isn't a regular
> file.

open_exec() is not used when bash decides to execute a script:
# cat > /dev/sda1
echo test
exit 1
^D
# chmod 644 /dev/sda1
#

$ bash /dev/sda1
test
$

I executed code on a block device.  Incidentally the device I used for testing 
was a USB flash device.  It seems to me that we want such devices to be 
removable_device_t not fixed_disk_device_t (as is currently the case).  Using 
removable_device_t will fix some usability cases but also make it more of an 
issue to control executing code from it.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: labeling of compilers etc

[Daniel J Walsh]

Russell Coker wrote:
> On Tuesday 31 January 2006 01:29, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>   
>> On Sun, 2006-01-29 at 11:56 +1100, Russell Coker wrote:
>>     
>>> In many discussions about hardening systems the idea is suggested that
>>> machines should not have compilers unless they are development machines.
>>>
>>> It would not be difficult to label compilers as compiler_exec_t and only
>>> permit user domains the ability to execute files of such type (daemons
>>> don't need to compile software).  What do you think of this idea?  Maybe
>>> we would want to have a more generic type such as devel_exec_t and label
>>> programs such as gdb with it as well.
>>>       
>> The other option would be to instead only label files that you want to
>> be executable by such users with a distinct type (e.g.
>> user_executable_t), and then remove access to the other types (bin_t,
>> sbin_t, *_exec_t, ...) from the user domains for such systems.  I
>> suspect that in such environments, you not only want to prohibit use of
>> the development toolchain, but also want to limit users to only
>> executing a specific set of approved programs.
>>     
>
> That sounds reasonable and fits with the SE Linux design philosophy of 
> default-deny.  Of course it'll be more fiddly to get it going acceptably.
>
>   
>>> Also interpreters could be modified to provide similar benefits. 
>>> Currently many (most?) shell interpreters try to detect and prevent
>>> setuid operation with code roughly equivalent to if(getuid() !=
>>> geteuid()) seteuid(getuid). Bash currently has such code (just done a
>>> quick test) and other shells had such cost in place last time I tested
>>> them.  I believe that this establishes a precedent for shell interpreters
>>> to check for and prevent insecure modes of operation.
>>>
>>> A logical extension of this precedent to SE Linux would be to have it
>>> check the type of a file to be executed and confirm that the current
>>> domain is permitted to execute scripts of the type in question, for a
>>> regular file it would get the context (after opening it) and ask SE Linux
>>> whether the current context has execute access for the file class.
>>>       
>> This is a policy issue at the kernel level, not something the shell
>> should get involved in.
>>     
>
> If the shell can read two files but should only "execute" one of them then 
> it's something that can only be enforced by the shell itself.
>
>   
>> If the policy author has decided to allow a 
>> domain transition and to mark a script with an entrypoint type, then
>> that is their choice,
>>     
>
> However it may not be their choice!  At any time a new version of some 
> software could replace an executable with a shell script.
>
>   
>> and it may be a perfectly valid choice in specific 
>> cases (e.g. shedding of permissions where subversion by the caller would
>> not yield any security risk since the caller already has more
>> permissions than the callee or where the caller is trusted).
>>     
>
> True.  The case of scripts escalating permissions is the one we are concerned 
> with.
>
>   
>> The 
>> current policy does make use of such transitions (e.g. init_t ->
>> initrc_t), so we certainly do not want to break them.
>>     
>
> Naturally we would not break them.  My proposal would still support such 
> things with a little extra policy.
>
> Below the line "domain_auto_trans(init_t,initrc_exec_t,initrc_t)" we would 
> merely have to add "domain_trans(init_t, shell_exec_t, initrc_t)".  The 
> policy changes would be introduced before the changes to shells so no 
> breakage would occur.
>
>   
>> It would make 
>> sense for a policy lint/checker tool (like sechecker) to check the
>> file_contexts configuration or filesystem state for scripts that have
>> entrypoint types and report on such transitions, flagging in particular
>> cases where the calling domain is not already more privileged than the
>> new domain for review by the policy writer or admin.  But I don't think
>> we want a blanket prohibition enforced by the shell.
>>     
>
> I did not suggest a blanket prohibition, but merely a prohibition controlled 
> by policy.  The number of instances where you really want to have a 
> domain_auto_trans() based on a shell script is very small so this should not 
> be difficult (absolutely no work at all when compared to the C coding needed 
> to get the shells all working with it).
>
>   
>>>   For a character device node
>>> (IE stdin but let's not assume that's the only device to be used) it
>>> would check for execute access of class chr_file for the context in
>>> question.  Does it even make sense to execute a block device node as a
>>> shell script?
>>>       
>> No.  open_exec() in the kernel rejects anything that isn't a regular
>> file.
>>     
>
> open_exec() is not used when bash decides to execute a script:
> # cat > /dev/sda1
> echo test
> exit 1
> ^D
> # chmod 644 /dev/sda1
> #
>
> $ bash /dev/sda1
> test
> $
>
> I executed code on a block device.  Incidentally the device I used for testing 
> was a USB flash device.  It seems to me that we want such devices to be 
> removable_device_t not fixed_disk_device_t (as is currently the case).  Using 
> removable_device_t will fix some usability cases but also make it more of an 
> issue to control executing code from it.
>
>   
Most of the applications that were named in this discussion would be 
blocked by a properly locked down domain anyways, by the name_connect check.

--
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: labeling of compilers etc

[Russell Coker]

On Wednesday 01 February 2006 13:34, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > I executed code on a block device.  Incidentally the device I used for
> > testing was a USB flash device.  It seems to me that we want such devices
> > to be removable_device_t not fixed_disk_device_t (as is currently the
> > case).  Using removable_device_t will fix some usability cases but also
> > make it more of an issue to control executing code from it.
>
> Most of the applications that were named in this discussion would be
> blocked by a properly locked down domain anyways, by the name_connect
> check.

What do you mean?  How does name_connect relate to executing code on a USB 
device?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
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: labeling of compilers etc

[Daniel J Walsh]

Russell Coker wrote:
> On Wednesday 01 February 2006 13:34, Daniel J Walsh <dwalsh@redhat.com> wrote:
>   
>>> I executed code on a block device.  Incidentally the device I used for
>>> testing was a USB flash device.  It seems to me that we want such devices
>>> to be removable_device_t not fixed_disk_device_t (as is currently the
>>> case).  Using removable_device_t will fix some usability cases but also
>>> make it more of an issue to control executing code from it.
>>>       
>> Most of the applications that were named in this discussion would be
>> blocked by a properly locked down domain anyways, by the name_connect
>> check.
>>     
>
> What do you mean?  How does name_connect relate to executing code on a USB 
> device?
>
>   
YOu mentioned confined domains calling out to tools like wget, ftp ... 
which would be blocked by name_connect.

--
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: labeling of compilers etc

[Russell Coker]

On Wednesday 01 February 2006 23:51, Daniel J Walsh <dwalsh@redhat.com> wrote:
> >> Most of the applications that were named in this discussion would be
> >> blocked by a properly locked down domain anyways, by the name_connect
> >> check.
> >
> > What do you mean?  How does name_connect relate to executing code on a
> > USB device?
>
> YOu mentioned confined domains calling out to tools like wget, ftp ...
> which would be blocked by name_connect.

tunable_policy(`httpd_can_network_connect_db',`
        # allow httpd to connect to mysql/posgresql
        corenet_tcp_connect_postgresql_port(httpd_t)
        corenet_tcp_connect_mysqld_port(httpd_t)
')

tunable_policy(`httpd_can_network_relay',`
        # allow httpd to work as a relay
        corenet_tcp_connect_gopher_port(httpd_t)
        corenet_tcp_connect_ftp_port(httpd_t)
        corenet_tcp_connect_http_port(httpd_t)
        corenet_tcp_connect_http_cache_port(httpd_t)
')

If either of the above booleans are on then there are plenty of connection 
options open.  I suspect that most significant Apache installations would 
need database connections.  Until we get the ability to install netfilter 
rules based on SE Linux context we have the situation that allowing 
connection to a database server on the LAN also means allowing connection to 
the same port on the public Internet.  If there is no firewall to stop this 
(the fact that there are Linux worms operating in such manner suggests that 
such firewalls aren't common enough) then that becomes an attack vector.  
Usually when someone starts a bot-net they have full control over a server 
and can serve such data on any port.

Also Apache can create files in the /tmp directory.  Presumably whatever 
method is used to execute an interpreter can also be used to write some 
arbitrary data in files under /tmp, or just pipe the data to the interpreter.  
The plan I outlined would prevent such execution.  It would allow any process 
that is permitted to execute bin_t and shell_exec_t to run 
"bash /bin/igawk" (igawk being a randomly selected bin_t labeled script on my 
system), but it wouldn't be able to run "bash /sbin/adsl-connect" unless it 
had execute access to sbin_t even if it had read access.

My plan would also allow us to permit a domain to use system(3) without 
permitting the execution of shell code (apart from that which can be passed 
as a command-line parameter).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: labeling of compilers etc

[Stephen Smalley]

On Tue, 2006-01-31 at 18:47 +1100, Russell Coker wrote:
> If the shell can read two files but should only "execute" one of them then 
> it's something that can only be enforced by the shell itself.

Except that domain transitions don't occur when you run the shell
directly, so we are only talking about an execve on a script, where the
kernel can adjudicate whether the script file is a valid entrypoint for
the domain.  Running bash on the same script won't yield the domain
transition.

> Naturally we would not break them.  My proposal would still support such 
> things with a little extra policy.
> 
> Below the line "domain_auto_trans(init_t,initrc_exec_t,initrc_t)" we would 
> merely have to add "domain_trans(init_t, shell_exec_t, initrc_t)".  The 
> policy changes would be introduced before the changes to shells so no 
> breakage would occur.

This is not exactly equivalent, see above.  Also, it should be possible
to eliminate the kernel race condition on interpreted scripts; Solaris
does this by pre-opening the script file and passing /dev/fd/<n> to the
interpreter so that there is second lookup of the script file.  This
still wouldn't make setuid/setgid bash scripts a good idea, but other
scripting languages may be more resilient to caller influence.

> open_exec() is not used when bash decides to execute a script:
> # cat > /dev/sda1
> echo test
> exit 1
> ^D
> # chmod 644 /dev/sda1
> #
> 
> $ bash /dev/sda1
> test
> $
> 
> I executed code on a block device.

Yes, but such execution will never cause a domain transition; you have
to do that via an execve of the script file, which has to be a regular
file.

>   Incidentally the device I used for testing 
> was a USB flash device.  It seems to me that we want such devices to be 
> removable_device_t not fixed_disk_device_t (as is currently the case).  Using 
> removable_device_t will fix some usability cases but also make it more of an 
> issue to control executing code from it.

-- 
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: labeling of compilers etc

[Stephen Smalley]

On Wed, 2006-02-01 at 08:45 -0500, Stephen Smalley wrote:
> This is not exactly equivalent, see above.  Also, it should be possible
> to eliminate the kernel race condition on interpreted scripts; Solaris
> does this by pre-opening the script file and passing /dev/fd/<n> to the
> interpreter so that there is second lookup of the script file.

The above should obviously be "...no second lookup of the script
file...".

>   This
> still wouldn't make setuid/setgid bash scripts a good idea, but other
> scripting languages may be more resilient to caller influence.

-- 
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: labeling of compilers etc

[Russell Coker]

On Thursday 02 February 2006 00:45, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Tue, 2006-01-31 at 18:47 +1100, Russell Coker wrote:
> > If the shell can read two files but should only "execute" one of them
> > then it's something that can only be enforced by the shell itself.
>
> Except that domain transitions don't occur when you run the shell
> directly, so we are only talking about an execve on a script, where the
> kernel can adjudicate whether the script file is a valid entrypoint for
> the domain.  Running bash on the same script won't yield the domain
> transition.

I probably should have split this discussion into two messages.  There are two 
issues here, that of domain_auto_trans() on shell scripts and that of general 
execution of shell code.

You are correct that there is no domain transition related to the script when 
the shell is executed directly.  However it's still desirable to enforce 
access control over which files can be executed.

> > Naturally we would not break them.  My proposal would still support such
> > things with a little extra policy.
> >
> > Below the line "domain_auto_trans(init_t,initrc_exec_t,initrc_t)" we
> > would merely have to add "domain_trans(init_t, shell_exec_t, initrc_t)". 
> > The policy changes would be introduced before the changes to shells so no
> > breakage would occur.
>
> This is not exactly equivalent, see above.  Also, it should be possible
> to eliminate the kernel race condition on interpreted scripts; Solaris
> does this by pre-opening the script file and passing /dev/fd/<n> to the
> interpreter so that there is second lookup of the script file.  This
> still wouldn't make setuid/setgid bash scripts a good idea, but other
> scripting languages may be more resilient to caller influence.

That is a really good idea.  You are correct that setuid and 
domain_auto_trans() shell scripts are still a really bad idea (the shell is 
far too dependent on environment variables etc).  But anything that makes 
hostile action more difficult is a good thing.

> > open_exec() is not used when bash decides to execute a script:
> > # cat > /dev/sda1
> > echo test
> > exit 1
> > ^D
> > # chmod 644 /dev/sda1
> > #
> >
> > $ bash /dev/sda1
> > test
> > $
> >
> > I executed code on a block device.
>
> Yes, but such execution will never cause a domain transition; you have
> to do that via an execve of the script file, which has to be a regular
> file.

True.  As mentioned above there are two issues related to shells.  One is 
domain_auto_trans(), the other is execution of code from hostile sources.


PS  I was inspired to start this discussion by a report of a real attack on a 
web server that was thwarted by the lack of a compiler, the attack would have 
succeeded otherwise.  Having no compiler installed on web servers is not the 
solution as the hostile code in question could have been written as a shell 
script, in Perl or in Python (which are all required to be installed on Red 
Hat systems and all but Python are required on almost every Linux system).

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: labeling of compilers etc

[Stephen Smalley]

On Thu, 2006-02-02 at 10:27 +1100, Russell Coker wrote:
> I probably should have split this discussion into two messages.  There are two 
> issues here, that of domain_auto_trans() on shell scripts and that of general 
> execution of shell code.
> 
> You are correct that there is no domain transition related to the script when 
> the shell is executed directly.  However it's still desirable to enforce 
> access control over which files can be executed.

True.  But it isn't clear what you gain from shell-enforced access
control when the shell is running in the caller's domain, because the
caller can then easily influence and control the shell in order to
bypass its checking (e.g. using LD_* variables, running the shell under
a debugger, etc).  This might require first importing precompiled code
into the target system from an external site, but that likely isn't
difficult if one gained access in the first place.

Stephen Smalley wrote:
> > Also, it should be possible
> > to eliminate the kernel race condition on interpreted scripts; Solaris
> > does this by pre-opening the script file and passing /dev/fd/<n> to the
> > interpreter so that there is no second lookup of the script file.  This
> > still wouldn't make setuid/setgid bash scripts a good idea, but other
> > scripting languages may be more resilient to caller influence.

Russell Coker wrote:
> That is a really good idea.  You are correct that setuid and 
> domain_auto_trans() shell scripts are still a really bad idea (the shell is 
> far too dependent on environment variables etc).  But anything that makes 
> hostile action more difficult is a good thing.

Yes.  If I recall correctly, one stumbling block in making the above
change in Linux is that in Linux, the /dev/fd/<n> links
-> /proc/self/fd/<n> links become inaccessible under setuid/setgid
(except for setuid to root, of course).  So one would have to alter that
restriction while still dealing with the potential leak issue there.  

-- 
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: labeling of compilers etc

[Russell Coker]

On Thursday 02 February 2006 23:32, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > You are correct that there is no domain transition related to the script
> > when the shell is executed directly.  However it's still desirable to
> > enforce access control over which files can be executed.
>
> True.  But it isn't clear what you gain from shell-enforced access
> control when the shell is running in the caller's domain, because the
> caller can then easily influence and control the shell in order to
> bypass its checking (e.g. using LD_* variables, running the shell under
> a debugger, etc).  This might require first importing precompiled code
> into the target system from an external site, but that likely isn't
> difficult if one gained access in the first place.

How would they get that precompiled code to be executed?  We want to make such 
things as difficult as possible.  One of the first aims of such work is to 
make all debuggers etc unavailable to such processes.

The shell is no easier to control via debuggers etc than any other process.

Also in regard to precompiled code the person writing such code must either 
know in advance what type of system is being targeted or send several 
sections of code for different systems.  The former requires more knowledge 
of the target than is often available and the latter requires bigger payloads 
and more attempts which increase the risk of detection.  People who are 
launching attacks on Linux systems now are using shell scripts and compiling 
source on the target machine because such methods provide them some benefits.  
So it seems worth-while to deny them such benefits.

> Russell Coker wrote:
> > That is a really good idea.  You are correct that setuid and
> > domain_auto_trans() shell scripts are still a really bad idea (the shell
> > is far too dependent on environment variables etc).  But anything that
> > makes hostile action more difficult is a good thing.
>
> Yes.  If I recall correctly, one stumbling block in making the above
> change in Linux is that in Linux, the /dev/fd/<n> links
> -> /proc/self/fd/<n> links become inaccessible under setuid/setgid
> (except for setuid to root, of course).  So one would have to alter that
> restriction while still dealing with the potential leak issue there.

Given that setuid/setgid scripts aren't supported anyway this shouldn't be an 
issue.  Any system that implements such setuid/setgid scripts (IE the 
perl-suidperl package) will also solve this problem because the script 
interpreter is not setuid/setgid and is run with the euid==uid and the 
egid==gid.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: labeling of compilers etc

[Stephen Smalley]

On Fri, 2006-02-03 at 22:15 +1100, Russell Coker wrote:
> How would they get that precompiled code to be executed?  We want to make such 
> things as difficult as possible.  One of the first aims of such work is to 
> make all debuggers etc unavailable to such processes.

LD_PRELOAD=evil.so bash

Now, I suppose that would fail if you are truly restricting execute
access for the user to a minimal set of programs and not giving them
execute to anything they can write (which btw eliminates the concern
about compilers, because they can then generate all the code they want
but they can't get it to execute, nor should any other domain be allowed
to execute anything they can write).

> The shell is no easier to control via debuggers etc than any other process.

My point was simply that if you are running the shell in the same domain
as other user processes, you have no isolation/protection guarantees for
the shell, and thus it can't truly be trusted to enforce any access
controls on the user.

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