[Fwd: Re: [uml-devel] 2.6.12-rc6-mm1 patches testing]

[Fwd: Re: [uml-devel] 2.6.12-rc6-mm1 patches testing]

[antoine]

-------- Forwarded Message --------
> From: Stephen Smalley <sds@tycho.nsa.gov>
> To: antoine <antoine@nagafix.co.uk>
> Cc: SELinux <selinux@tycho.nsa.gov>, Blaisorblade
> <blaisorblade@yahoo.it>
> Subject: Re: [uml-devel] 2.6.12-rc6-mm1 patches testing
> Date: Thu, 09 Jun 2005 15:45:49 -0400
> On Thu, 2005-06-09 at 19:04 +0100, antoine wrote:
> > > UML needs simply to mmap (PROT_EXEC) datas from the /tmp/vm_XXXXXX file to 
> > > work, and so it tries doing this very early, to give the user a hint on what 
> > > happens. On a fs mounted noexec this is forbidden, so possibly it's forbidden 
> > > also by SELinux; however, it would be nicer if SELinux could simply allow 
> > > mmap()ing with PROT_EXEC without allowing file execution...; allowing mmap() 
> > > does not put a big hole inside protections while allowing file execution 
> > > does...means that if the user can supply a program to execute, that program 
> > > can be written to mmap() and execute code from /tmp, but at that point the 
> > > intruder could simply execute his code.
> > 
> > Can anyone answer this for us please?
> > I am trying to workaround this:
> > audit(1117846877.640:0): avc:  denied  { execute } for  pid=29031 comm=um-kernel path=/tmp/vm_file-NnIm5X (deleted) dev=md7 ino=3965039 scontext=root:sysadm_r:um_kernel_t tcontext=root:object_r:um_tmp_t tclass=file
> > Without giving uml execute access to its tmp directory.
> 
> Possibly the UML folks could elaborate on what UML is trying to do here?
> In the long term, I'd advise changing its behavior if possible, as
> allowing execution of arbitrary code is obviously undesirable and use
> of /tmp will break noexec /tmp mounts as noted above regardless of what
> SELinux does.
> 
> In the short term, you naturally have the option of adding:
> 	allow um_kernel_t um_tmp_t:file execute;
> to your policy as a workaround.  This shouldn't actually allow direct
> execve() of such files, as that would also trigger another check
> (execute_no_trans if staying in the same domain or entrypoint
> otherwise), but would allow indirect execution via ld.so (if staying in
> the same domain).




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[Fwd: Re: [uml-devel] 2.6.12-rc6-mm1 patches testing]

[antoine]

I thought this could be of interest to all UML devs:

(as far as I'm concerned, the /tmp is already in its own space in a chroot so
this is not an issue)

-------- Forwarded Message --------
> From: Stephen Smalley <sds@tycho.nsa.gov>
> To: Blaisorblade <blaisorblade@yahoo.it>
> Cc: antoine <antoine@nagafix.co.uk>, SELinux <selinux@tycho.nsa.gov>
> Subject: Re: [uml-devel] 2.6.12-rc6-mm1 patches testing
> Date: Fri, 10 Jun 2005 09:35:27 -0400
> On Fri, 2005-06-10 at 00:57 +0200, Blaisorblade wrote:
> > However, since UML is a virtual kernel, between its task there is executing 
> > programs, in the memory of the virtual guest; this memory is represented by a 
> > host file, because it must be shareable by different threads (each of them 
> > matches one process/thread executed inside UML; actually there are 
> > complications but this is the base idea).
> 
> Shared anon mapping?
> 
> > A note: this file is later deleted to avoid it being touched by the host; what 
> > I was thinking was if this could be extended to deleting the directory it's 
> > in (it could, and this would work); then, maybe the execute permission could 
> > be given only to the directory, and the creation of such directories could be 
> > restricted to UML (well, given that you make UML put his files not in /tmp 
> > but in a reserved place). I.e.:
> 
> It is already the case that a separate type (um_tmp_t) is being applied
> to the file, and I presume that the policy only allows um_kernel_t to
> create/modify files with this type, so policy should ensure that no
> other process can touch the file and that no other process can trick uml
> into using a different file (because um_kernel_t will lack execute
> permission to any other xxx_tmp_t type, and thus the mmap would fail).
> 
> > only the UML "role" (I don't know SELinux so please correct me) can create a 
> > folder under /chroot/mem; those folders become of a different role
> > with auto_trans, inside those folders you get execute permission with "allow 
> > um_kernel_t um_tmp_t:file execute;", and those folders get deleted as soon as 
> > the file has been created, opened and deleted, so only UML can create an 
> > mmap'able file; race condition to check here if the attacker creates a file 
> > while the directory exists but not difficult to solve; I guess this is 
> > possible with SELinux.
> 
> Moving from /tmp to a dedicated location with its own type or using a
> shared anon mapping would make it clear that we are dealing with
> something other than a normal /tmp file, as well as fixing the
> noexec /tmp problem.  As far as an attacker creating a file, policy
> should prevent them from being able to create a file in the necessary
> type to allow execution, so that shouldn't be a problem.  Naturally, if
> uml itself is subverted, it may be induced to execute arbitrary code
> from the memory.
> 
> > I don't understand the domain concept... however, by "indirect execution" you 
> > mean simply running /lib/ld.so <fileName>, don't you? In this case, since the 
> > kernel must just mmap() ld.so and not execve() it, couldn't we deny 
> > execve("/lib/ld-linux.so") via the checks you mentioned above?
> 
> Yes, execute_no_trans would also apply there.



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel