Closed Bug 1285827 Opened 8 years ago Closed 8 years ago

Seccomp sandbox violation: sys_link called in content process of Firefox desktop

Categories

(Core :: Security: Process Sandboxing, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla50
Tracking Status
firefox50 --- fixed

People

(Reporter: tedd, Assigned: tedd)

References

Details

Crash Data

Attachments

(1 file)

I think we can whitelist this, we already have a bunch of other file system access calls whitelisted. This will probably also be a case that should be handled by the file broker. :gcp what do you think?
Flags: needinfo?(gpascutto)
link() can be treated similarly to open()+write(), I guess.
Flags: needinfo?(gpascutto)
Assignee: nobody → julian.r.hector
Attachment #8769781 - Flags: review?(gpascutto)
Comment on attachment 8769781 [details] [diff] [review] Add sys_link to seccomp whitelist r=gcp Review of attachment 8769781 [details] [diff] [review]: ----------------------------------------------------------------- Are we able to send these to the file broker at some point?
Attachment #8769781 - Flags: review?(gpascutto) → review+
Should be possible, all wee need to do is pass two file paths to the parent and somehow that it should create a link. Whitelisting what can be linked where shouldn't be too hard either.
Keywords: checkin-needed
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
Crash Signature: [@ libc-2.19.so@0xece07 ]
The two crash reports currently on file for this both mention libuim-mozc.so, which is a Japanese text input plugin. If that's the only thing that's trying to link(), and assuming that only the parent process actually needs working text input, we might be able to get away with just denying the link() call instead of brokering it.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: