qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] security_20040618


From: Tim
Subject: Re: [Qemu-devel] [PATCH] security_20040618
Date: Sat, 19 Jun 2004 08:19:31 -0700
User-agent: Mutt/1.5.6+20040523i

> In dyngen you need to do:
> 
> if ( ptr == NULL )
>       error("malloc failed");
> 
> error() will never return.
>
> For the other places it depends, but it's ususally quite simple. Why not
> have a stab and submit a seperate patch on top of this one?

You would prefer I submit a seperate patch for the malloc fixes?  I
could certainly do that, but I just figured it is all a general code
quality patch, which changes very few lines of code (though in many
files).  What would you prefer Fabrice?
 
> Also - Abother low hanging fruit may be /tmp file races. You could
> probably make sure mkstmp is being used where possible etc.. and/or use
> of /tmp files elimated as much as possible.... Or try setup a
> $(HOME)/.qemu dir for that stuff. I know QEMU_TMPDIR is checked in vl.c
> but the standard TMPDIR probably ought to be aswell if we DO use /tmp.
> 
> I mean, if root saves log to /tmp/qemu.log any user on the system may
> obliterate any file (ln -s /etc/passwrd /tmp/qemu.log) as /tmp is the
> default choice, perhaps root should know better, but maybe we should use
> sane defaults like $(HOME)/qemu.log.

Heh, funny you mention it... that was next on my list.  I noticed the
logging to /tmp a while back, but didn't want to open up that can until
I understood the codebase a little better.

For my purposes, I would like to run qemu as more of a daemon than
anything.  So, I will likely attempt some improvements to the command
line logging options, and pick safe defaults.  I'll try to eliminate
other temp files where possible, and make the others secure against
races.  We'll see, I haven't even looked at that code yet... 

> If people are interested in janitorial stuff like this, please, go right
> ahead :)

Yeah, well I certainly am.  Call me anal retentive if you like, but I
really prefer to use software that's rock-solid when it comes to
stability and security.

tim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]