 Hi everyone. Nice to meet you. My name is Chung-Han Kang. I'm working for the Opiliated Institute of Atree in South Korea. First, I hope everybody and everyone will be fine and safe from the coronavirus. Today, I'm going to talk about XSM, X.org Security Module. Introduction. As you see, the X-Windows system, also known as X11, X.org, serves a Windows-style graphing user interface on our desktop. It allows multiple programs to share access to a screen, keyboard, and mouse by X clients and X server architecture. If you type on a keyboard and click on mouse button, the input signal will be sent to a Windows program you are using. So every input and output data goes through X server. Thereby, it results in security and privacy issues. For instance, there are three functions about it. Clipboard, screen capture, accession, record, and replay. They handle a meaningful data for desktop users, or copy, text, or current screen image, and video, keystrokes, and mouse clicks. You know, X.org is known as serving a poor isolation between X clients. So the meaningful data can be stolen by another X client without difficulty. Before we move on the next page, I want to make something clear about X.org-first-wellend. Because XSM is for X.org only, on the right-hand side, it explains why Ubuntu shipped X.org-5 default. We know Wellend is a rising star and it's maturing. Wellend is shipped on many distributions today, but X.org is used on many distributions too. So I thought developing XSM is a necessary work. Before we look into XSM, we need to check three security functions in X.org. As we check them, we can guess X.org developers have been concerned about their security and private issues. First, X security extension. It shipped on X.org when I went to an elementary school. I mean, it was a long time ago. It serves trusted and untrusted mode. If your program is on untrusted mode, then screenshots and screencasts are not working, but it is unstable. The untrusted window program becomes weird. We can't control the window size and position on the mode. Second, X access control extension. I'm sure it's great work. It hooks X.org functions like Linux security module. X access control extension is based on the X access control extension, and I also refer to the X access control extension for XSM. Last, X access Linux. It is designed to control X.org by access Linux policy. Unfortunately, it is disabled by default now. I tried to use it many times, but enabling access Linux, setting and debugging the access Linux policy were a terrible job. As a result, I regarded the security functions in X.org are not working well and unsuitable to solve the issues right away. But the issues are serious for desktop users. Our meaningful data can be linked to any adversaries without difficulty. So I was motivated to develop XSM. Try an error. In this part, I will show you my journey to solve the privacy issues from X client and X server. At first, I didn't know about X.org internals, so I was looking for the solution on X client level. I attempted to limit an execution of the screenshot and screencast files by the file access control. You know, there are so many applications, uncountable, like well-known and self-developed. So I thought it is impossible to control all of them. Next, Hooking Library Function Core. I used to believe I can hook key functions for my goal by LD Preload. As you see now, I was able to find out many key functions. However, I wasn't sure. I didn't miss other key libraries and functions. And I wasn't able to hook some programs by LD Preload, such as C++ Python. Next, I found a way to restrict the clipboard access by GTK library. The source code means owning a clipboard data and then clearing the data. So it empty clipboard data first whenever the copy and control C operation happens. This approach is very useful for a clipboard only. Anyway, I was convinced I have to move my focus to X server. There is three security functions in X server, such as X security extension, X access control extension and X asset Linux. After I looked into them, I got an idea using X access control extension for XSM. As I mentioned, X security extension and X asset Linux were not enough to serve the security issues on X.org. But they have very useful information. Eventually, I referred to them to develop XSM. In detail, on the right side of the image, it shows an example of X access control hook calls. The proc createPixMap is a function in the X server called from createPixMap in the X client. And the code flow of X asset Linux, the first square bracket is in the X client. The second square bracket is in the X server. Let's have a look at X or security module. XSM is a loadable module of X.org. For additional security features, we don't need to modify X.org source code. Anyway, XSM SO file is installed in the extension's path. Then we have to restart X.org process to apply XSM. As I said, XSM is based on X access control extension. It limits the API calls from X clients. X access control extension is only valid on DIX, device independent X, and OS layer in X.org. So XSM can control functions and variables in X.org for the security and privacy issues. To look for the key function and variable, I monitored X.org internals by log messages and X trace tool. As you look at, I found out those functions. XSM identifies the functions by the X access control who with applications like clipboard, screenshot, and screencast. Implementation. I implemented and tested XSM on the environment. Especially the desktop environment like Cinnamon norm are very important. Because they cause some errors for XSM, I'm going to explain the details on discussion. This is a configuration file of X.org for XSM. XSM can be loaded if the configuration file is in the path. To develop XSM, I needed to know a template code for X.org module. As you see, they are essential symbols. If you wonder the details, please check out XSM source code on Appendix page. It will be useful to make your X.org module as well. XSM has three main Carbac functions. XSM extension, XSM resource, XSM selection. They are registered by X access control extension. They hook X.org functions related with the hook identifier. Let's have a look for the three Carbac functions in detail. XSM selection handles the clipboard access like that. The clipboard access is identified by a request name, add name, and a window value. XSM resource and XSM extension limit the screenshot and screencast. In fact, XSM extension is only for controlling a mouse cursor image. It's not very important in this part. But, XSM resource is very important function. It controls on access to get image and copy area calls. Additionally, the MIT SHM get image sends a bigger data buffer than X11 get image. So, it might be used for the screencast recording video. XSM extension also handles hooking X session record and replay like that. X test means on X.org extension for replaying input data. XSM controls the access by the request name. XSM policy and logging. XSM has a policy file like that. It uses iLogify mechanism to recognize changing the policy file. Also, XSM saves a log data to journal about XSM event such as changing policy, preventing a clipboard access screenshot, and so on. Evaluation. I tested XSM with various applications. I also used some screenshot applications I made. I checked out XSM prevent all of them exactly. Discussion. As you know, there is no solution without a side effect. The first is non-share issue on non-environment. It also made two sub-issues. One is non-share, the screenshot whenever any change occur on my screen. If XSM disallowed the screenshot, my screen froze. Certainly, it was stopped. For this issue, I added a whitelist in XSM to bypass the non-share. Another is related to the first one. The non-screenshot is not real screenshot on the non-environment. I figured out the non-share is in charge of screenshot. On the right side, on the non-environment, if screenshot request happened, screenshot calls a divorce method. And then, non-share takes a screenshot and saves on image file. Another is about unclipboard access. This is not a serious issue, a little annoying. If a clipboard manager tool is working, the clipboard manager tries to access the clipboard data continually, and provides that XSM disallows the clipboard access. It makes XSM rules too. I thought it is annoying. So I modified XSM to terminate the clipboard manager as an option if it happened again. The last is about testing. XSM may be not perfect because I didn't test all of applications with XSM. I'm not sure. XSM is valid on other applications I missed. So continuous maintenance against other applications will be essential job. Conclusion. So far, I have talked about XSM. The reason why I developed XSM is serving privacy issues on X-Windows system, X.org. The privacy issues are caused by a poor isolation of X.org. On X.org environment, an X client can steal another X client's data, such as copied text, captured images and video, keystrokes and mouse clicks. To solve these issues, XSM has three main features like that. Load of modules, limiting API calls related to privacy issues via access control hooks, looking for key functions and structures to limit them. For future work, I'd like to improve XSM with testing other applications, watermarking on a screenshot and screencast file, and GUI polish editor and supporting polish key. Remained pages are about reference and appendix. Appendix page is for X.org architecture and access control specification. Also, you can watch a demo video and download our XSM source code on the URL on the page. Any question?