Re: labeling of compilers etc

["Lorenzo Hernández García-Hierro" <lorenzo@gnu.org>]

[-- 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 --]