Re: clamav RWX

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 12 Jul 2010 16:26:54 -0400
Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:

> On Mon, 2010-07-12 at 21:08 +0300, Török Edwin wrote:
> > On Mon, 12 Jul 2010 12:31:11 -0400
> > Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
> > 
> > > On Mon, 2010-07-12 at 15:55 +0300, Török Edwin wrote:
> > > > On Mon, 12 Jul 2010 07:48:29 -0400
> > > > Eric Paris <eparis@xxxxxxxxxxxxxx> wrote:
> > > > 
> > > > > 2010/7/12 Török Edwin <edwintorok@xxxxxxxxx>:
> > > > > 
> > > > > > [*]
> > > > > > I have some plans to make the JIT work without RWX, since
> > > > > > ClamAV has 2 phases:
> > > > > >  - load DB, JIT compile bytecode (should use only RW-
> > > > > > mapping, but currently needs RWX)
> > > > > >  - execute (JIT compiled) bytecode (should change mapping
> > > > > > to be R-X)
> > > > > 
> > > > > Just so you know that is going to require the same
> > > > > permissions. (Hopefully) The only way to get around the
> > > > > SELinux permissions is to have 2 separate mappings.
> > > > > Basically in really really rough sudo-code,
> > > > > 
> > > > > file = open(filename, RWX);
> > > > > unlink(file);
> > > > > truncate(file, however big you need);
> > > > > exec_area = mmap(PROT_EXEC, file);
> > > > > write_area = mmap(PROT_WRITE, file);
> > > > > 
> > > > > then do all of the writing to write_area and all of the
> > > > > executing in exec_area.
> > > > > 
> > > > > http://people.redhat.com/drepper/selinux-mem.html
> > > > 
> > > > Yes I've seen that page, however that is not going to be so
> > > > simple. All the relocations are done assuming that the code
> > > > will be executed where you write it to (and all absolute jumps
> > > > are generated the same way).
> > > > Changing that would be a lot of work, and could introduce new
> > > > bugs.
> > > > 
> > > > > 
> > > > > Simply using mremap to change a mapping from PROT_WRITE to
> > > > > PROT_EXEC will cause the same problems as just doing it at the
> > > > > same time.
> > > > 
> > > > Then I'd better write a small testcase before converting LLVM
> > > > to do that.
> > > > IIRC I tried something like that and worked, but I could have
> > > > done something wrong. Will try again to be sure.
> > > > 
> > > > Is there a boolean (other than execmem) that would allow RW ->
> > > > RX mprotect()?
> > > 
> > > For a private anonymous mapping, we always check execmem if
> > > PROT_EXEC (even for a RX mapping), as it still represents making
> > > executable arbitrary data (not tied to any file or covered by an
> > > file-based checks).  So you have:
> > > Private anonymous mapping RW => no checks
> > > Private anonymous mapping RX => execmem
> > > 
> > > For shared file mapping, we have:
> > > Shared file mapping RW => read, write to file
> > > Shared file mapping RX => read, execute to file
> > 
> > So if I map a tempfile as RW, write my JITed code to it, then
> > mprotect to RX will it work without 'execmem'?
> 
> That would remove the requirement for execmem, yes.  But clamd_t and
> freshclam_t would then require appropriate permissions to the file,
> including create, unlink, read, write,

I would have these permissions for something in /tmp, right?

> and execute.

I probably wouldn't have this though.

>  You can avoid the
> create+unlink requirement by mapping /dev/zero or using MAP_SHARED|
> MAP_ANONYMOUS, but you'd still need RWX to the file.  So I'm not sure
> what we gain there.

If I can change the mapping from RW <-> RX, then the mapping is
writable only for a brief period (DB reload), so an exploit can't take
advantage of the RWX mapping (since there is no RWX mapping).
Thats better than allowing 'execmem' for the entire process, isn't it?

Best regards,
--Edwin


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.


[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux