Page MenuHomePhabricator

Re-enable the Score extension in safe mode
Closed, ResolvedPublicSecurity



This task:

  • Await completion of security audit at T257090.
  • Address any incident follow-ups (see sub tasks).
  • Address any issues from the security audit.
  • Determine whether the Firejail config that MW generates for Score is sufficient. Make any tweaks as needed. For example, do the limits for walltime, memory, and filesize work as expected and do they need tuning.
  • Re-enable Score extension in safe mode if we are comfortable with that.

Source code of Score's Shell+Firejail command:

Event Timeline

  • Re-enable Score extension in safe mode if we are comfortable with that.

For the unsafe features, I suggest we file separate (public) tasks after all this is dealt with. We could also re-open the original tasks for them instead (which were closed after safe mode was disabled with T174413 in 2017).

It was mentioned by @faidon that some of the "unsafe" features seem to have nothing unsafe about them and may've been disallowed by mistake. If that is the case we could try to work with upstream to allow those by default.

I believe someo the features considered "unsafe" by upstream may've been marked that way not for security reasons but for resource/availability reasons, e.g. if they allow unbounded growth in some way. Given we run in a firejail, we would likely be fine with enabling those things. Perhaps it would make sense for LilyPond to have a new mode in-between safe and unsafe, like "advanced" or something that allows these useful advanced capabilities (with the caveat that people should only deploy that with a ulimit/firejail wrapper). But this advanced mode (unlike the "unsafe" mode) would not expose the full Scheme/Guile programming feature set with sockets, file operations, shell commands etc. We don't want to allow that from wikitext, ever, not even in a firejail.

lilypond -dsafe does not fix exploits available via ghostscript, which lilypond calls without -dSAFER (which would disable opening other files, opening pipes and execing other binaries, etc.)

(see T257092 for more about this)

Reedy changed the task status from Open to Stalled.Jul 6 2020, 3:29 PM
Reedy subscribed.

Marking as stalled as various things to be considered and potentially implemented before this can be done

tstarling claimed this task.

I did null edits on all the pages in , and now there are none left. Then I did null edits on all the main namespace pages in , which left only two. I fixed Prelude and Fugue in E minor, BWV 855 and submitted for it. First call is a more difficult case -- I just removed the staff size override since it's hard to support and it doesn't really need to be there.

So first impressions are that safe mode is not as bad as I thought it would be.

tstarling closed subtask Restricted Task as Resolved.Aug 4 2020, 5:54 AM
tstarling reopened subtask Restricted Task as Open.Aug 12 2020, 6:53 AM
Joe subscribed.

And disabled again.

@tstarling Given you are currently assigned to this task: Is there any work currently being done on this? Asking in context of ankry's comment at T257066#6622631.

sbassett triaged this task as Medium priority.Aug 4 2021, 7:10 PM
sbassett moved this task from Waiting to Watching on the Security-Team board.
sbassett changed Risk Rating from N/A to Medium.
Legoktm subscribed.

A security audit and risk exercise was conducted of Score+Shellbox. The LilyPond security audit is incomplete/still in progress, but we've decided that OK if LilyPond still has safe mode escapes.

Legoktm changed the visibility from "Custom Policy" to "Public (No Login Required)".Aug 20 2021, 9:48 PM
Legoktm changed the edit policy from "Custom Policy" to "All Users".
sbassett closed subtask Restricted Task as Declined.Mar 22 2022, 5:04 PM