qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Tim <tim-qemu@sentinelchicken.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] security_20040618
Date: Sat, 19 Jun 2004 08:19:31 -0700	[thread overview]
Message-ID: <20040619151931.GC1962@sentinelchicken.org> (raw)
In-Reply-To: <1087636303.3375.200.camel@sherbert>

> 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	other threads:[~2004-06-19 15:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-18 18:40 [Qemu-devel] [PATCH] security_20040618 Tim
2004-06-19  9:11 ` Gianni Tedesco
2004-06-19 15:19   ` Tim [this message]
2004-06-19 15:26     ` Gianni Tedesco
2004-06-19 15:44 ` Fabrice Bellard
2004-06-19 16:01   ` Tim
2004-06-19 17:11     ` Fabrice Bellard
     [not found] <200406181841.i5IIfZQa019337@treas.simtreas.ru>
2004-06-19  7:37 ` Vladimir N. Oleynik
2004-06-19 15:05   ` Tim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040619151931.GC1962@sentinelchicken.org \
    --to=tim-qemu@sentinelchicken.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).