Re: [Lcd4linux-devel] make lcd4linux secure!

[Jerry S. <ye...@th...>]

On Tue, May 25, 2004 at 10:08:18PM +0200, Michael Reinelt wrote:
> Hi there,
> 
> I want lcd4linux not to contain any potential security holes. As we 
> don't have any networking, no client-server-model, no other fancy stuff, 
> this risc is quite low. But lcd4linux is running as root, and therefore 
> potentially dangerous.
> 
> I'm worrying about a symlink security hole: The Image driver (was: 
> Raster) creates files, without checking if they exist. If a user places 
> a symlink, he may use lcd4linux to overwrite arbitrary files. Which I 
> consider not to be nice.
> 
> The output file of the raster driver is passed with the '-o path/file' 
> option. To enshure that a potential reader always gets a complete file, 
> the image is first written to a temp file, which will be rename(2)'ed 
> afterwards.
> 
> I see two problems here:
> 
> 1. the temp file is opened with O_CREAT. If a symlink is already 
> present, it's target will be overwritten. Some security HOWTO's say one 
> should use O_CREAT|O_EXCL, which means that the call will fail if the 
> file already exists. OTOH, the open(2) man page states that thios 
> doesn't work over NFS :-(
> 
> 2. the rename() will overwrite a symlink, too.
> 
> 
> Anybody out there with the experience how to solve such issues? I didn't 
> find too much documentation out there, especially not for exactly the 
> cases we're dealing with here.

There are a few things you can try, each with their own limitations...

1. Use mkstemp() to create the filename.  With a random filename, it
becomes much harder for a hacker to misuse the file.  I don't know if or
how you can get the filename for the file created by mkstemp().

2. Write the file to a directory owned by root.  /tmp can be a bad place
for secure files because anyone can write to it.  Then the rename
technique would work.

However, I think that your solution above is reasonable.  It is pretty
much assumed that if you want a secure setup you won't use NFS.
Furthermore,  it is not common practice to use NFS for /tmp.

As far as using a symlink to subvert the rename operation, there really
isn't anything you can do about that.  It is a sysadmin issue.  The
program is run by root and shouldn't be writing to a directory that
other users also have write access to.

Jerry

-- 
Jerry Seutter

Email: ye...@th...
Web: http://www.thegeeks.net/~yello
Gallery: www.thegeeks.net/~yello/gallery (email me for username and password).