Re: [Denemo-devel] Denemo music-vault / scheme security risks

[Richard Shann]

On Sat, 2009-05-02 at 23:34 +0200, Nils Gey wrote:
> I'm currently working on a way to build a .denemo vault on denemo.org where 
> users can share their music.
> 
> Of course this will only be succesfull if users can upload and maintain their 
> files themselves and the files have not to be reviewed by the denemo-team 
> first.
> 
> There are two issues: 
> 1)Copyright.
>  This is a typical one. Like many services and places of the web where things 
> can be shared there is a possibility that copyrighted material will be made 
> avaible. 
> 
> There is no working solution for this except: remove when discovered. I 
> suggest we will excatly do that on denemo.org: Allow any .denemo notation to 
> be uploaded and when we discover illegal material or if anyone complains we 
> just delete it and probably ban the user-account. (Of course banning has no 
> real effect because its free and unrestricted to make a new account)
> 
> I expect not many cases to happen... notation is not mp3.
I agree.
> 
> 2)Security
> Richard told me that the scheme-code inside denemo-files can harm your system.
And LilyPond code (because it can include scheme code)
> 
> But we have to think about ways to warn and to protect the users. 
> There are two steps: Website and inside denemo.
> 
> Now what can denemo files do and what ways are there to restrict denemos 
> scheme access on the users system?
On reading in a Denemo file we could reject all LilyPond, but
increasingly Denemo is using canned LilyPond rather than hardwiring it
into the source code of the executable. It would be counter-productive
to start trying to decide if a given piece of LilyPond code was an
acceptable piece of canned code, since we wish to develop the canned
code rapidly with the aid of users, once it becomes easy enough.

When invoking LilyPond there are two levels of safe-mode, but I rather
suspect that trying to invoke these from a program would result in
frequent failures (one, for example, would reject all include files, so
the drum stuff would stop working).
> 
> If it is enough to restrict inside denemo then we don't have to install 
> anything on our website to check the files.
> 
> Of course warning and simple checks are easier. First only .denemo files 
> which are mime-type application/x-gzip can be uploaded to our site (this 
> already works). 
this won't stop the obvious attack
> And we can add a disclaimer "Be careful with downloaded .denemo-files" but 
> people tend to just ignore such warnings
yes, I don't think we should just do that.

We could have a command that would extract and display all the LilyPond
that is contained in the file (that is all the user-added stuff, not the
denemo generated stuff). This would make it possible for a savvy person
to look it over for suspicious code. So if someone posted up something
it could await approval with its embedded LilyPond visible.

We could have something to prevent printing of Denemo files that have
been downloaded (tag the files that are uploaded so that Denemo can
recognize the fact).

Some of this applies to new Denemo commands, which are easier to
display, being straight scheme code. It would still require someone
experienced in the language to say that it was not malicious code.

Richard


>  and just load the files anyway.
> 
> Nils
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel