It’s been more than 3 years since my last se­cu­rity-re­lated blog post. One might think I lost in­ter­est but the re­al­ity is that I just suck at blog­ging. This blog post is meant as a sum­mary of a de­bate a few of us had pri­vately and pub­licly on the Way­land ML.

Dis­claimer: Al­though I try to be up to date with every­thing that sur­rounds se­cu­rity of X11 and Way­land, what I write in this ar­ti­cle may be out­dated, in­com­plete or sim­ply bla­tantly wrong. This ar­ti­cle be­ing the ba­sis for a doc­u­ment I’m plan­ning on writ­ing to help Way­land com­pos­i­tor de­vel­op­ers im­ple­ment se­cure com­pos­i­tors, I would love to hear your feed­back!

1. The needs be­hind every se­cu­rity prop­erty

Be­fore dwelv­ing into how to se­curely ex­port priv­i­leged fea­tures to graph­ics servers, let’s first have a look at the dif­fer­ent se­cu­rity prop­er­ties that can be ex­pected by users. I’ll try to il­lus­trate all of them with a sim­ple ex­am­ple that should be im­por­tant for every­one. Of course, we can imag­ine many other sit­u­a­tions but that’s an ex­er­cise left to the reader.

On a graph­ics server, the user can only be con­cerned about 2 cases, in­put and out­put. The in­put be­ing what is used by the user to in­ter­act with the com­puter while the out­put is what is dis­played back to the user.

Con­fi­den­tial­ity

In­put con­fi­den­tial­ity means that only the ap­pli­ca­tion that is sup­posed to get the key­board and mouse events re­ceives them. This is im­por­tant to avoid sit­u­a­tions where a ma­li­cious ap­pli­ca­tion would record key­board strokes while you en­ter a pass­word (key-log­gers) or record your mouse move­ments when click­ing on a graph­i­cal digit key­board (used by some bank web­sites to au­then­ti­cate you). The re­sult of both cases is that you’ve lost your cre­den­tials’ con­fi­den­tial­ity and some­one can now im­per­son­ate you.

Out­put con­fi­den­tial­ity means an ap­pli­ca­tion should not be al­lowed to read back what is dis­played by other ap­pli­ca­tions or the en­tire screen. At the mo­ment, any ap­pli­ca­tion can read the whole screen’s con­tent. This is prob­lem­atic when e-shop­ping be­cause af­ter key­ing-in your credit card num­ber, it is dis­played and one screen-shot can leak those bank cre­den­tials (when the heck will they get their shit straight?). No out­put con­fi­den­tial­ity ba­si­cally means that what­ever you can read can be read by an­other ap­pli­ca­tion (and likely be sent over the in­ter­net too).

In­tegrity

In­put in­tegrity means that no ap­pli­ca­tion can pre­tend to be the user and send forged in­put to an­other ap­pli­ca­tion. If this were al­lowed, ap­pli­ca­tions could per­form con­fused deputy-like priv­i­lege es­ca­la­tions. In­tegrity doesn’t only mean that the in­put hasn’t been tam­pered with, it also means that the source of the data re­ally is the one ad­ver­tised. With­out in­tegrity, if an ap­pli­ca­tion was not al­lowed to di­rectly ac­cess a file but the user could, the ap­pli­ca­tion would only have to fake send­ing the “Alt + F2” key se­quence and key-in the com­mands it wants to ex­e­cute. This isn’t prob­lem­atic in poorly-se­cured Op­er­at­ing Sys­tems but be­comes a prob­lem when ap­pli­ca­tions start run­ning with less priv­i­leges than the user who started them.

Out­put in­tegrity means no ap­pli­ca­tion can mod­ify the con­tent that is dis­played by an­other ap­pli­ca­tion. It also means non-re­pu­di­a­tion of the out­put con­tent, if it is on the screen, it re­ally comes from the ap­pli­ca­tion it claims to be from. An at­tack sce­nario could be for an ap­pli­ca­tion to launch Fire­fox on the URL http://​www.​hsbc.​fake.​com which would be a copy of the HSBC web­site, ex­cept it would steal your cre­den­tials be­fore redi­rect­ing you to the real one. With no out­put in­tegrity, the ma­li­cious ap­pli­ca­tion could al­ter the URL bar of Fire­fox to make it look like you are con­nected to https://​www.​hsbc.​com and not http://​www.​hsbc.​fake.​com. This would make the at­tack im­pos­si­ble to vi­su­ally de­tect, even by care­ful users.

Avail­abil­ity

A ser­vice is avail­able if le­git­i­mate users can ac­cess it when­ever they want. One way to make other ap­pli­ca­tions not avail­able is for an ap­pli­ca­tion to run full-screen and not al­low­ing the user to switch back to us­ing other ap­pli­ca­tions. This fea­ture is use­ful for screen lock­ers but ap­pli­ca­tions such as games of­ten make use of it, which can be very an­noy­ing. It has also been found that at least one anti-cheat sys­tems took ad­van­tage of games run­ning al­ways in the fore­ground in or­der to use the com­pu­ta­tional power of the gamer’s PC to mine bit­coins, mak­ing it harder for users to re­alise the prob­lem.

In­put avail­abil­ity means no ap­pli­ca­tion can redi­rect all/most of the user’s in­put to it­self, pre­vent­ing other ap­pli­ca­tions from re­ceiv­ing in­put when the user in­tended them to. This can be achieved by not al­low­ing un­con­di­tional rout­ing of events to a sin­gle ap­pli­ca­tion, thus block­ing the com­pos­i­tor from re­ceiv­ing events for the Alt + Tab short­cut.

Out­put avail­abil­ity means no ap­pli­ca­tion can pre­vent other ap­pli­ca­tions from dis­play­ing their con­tent on the screen, if the user de­sires to see that con­tent. An ex­am­ple would be an ap­pli­ca­tion be­ing full-screen and “top-most”, thus block­ing users from view­ing/ac­cess­ing other ap­pli­ca­tions.

2. Im­prov­ing the se­cu­rity of X

At XD­C2012, Tim and I gave a pre­sen­ta­tion about the se­cu­rity of the Linux graph­ics stack which has been re­layed by LWN and Lin­uxFR. The re­sult wasn’t pretty, as in­deed a user can ex­pect nei­ther con­fi­den­tial­ity nor in­tegrity or avail­abil­ity on in­puts and out­puts when us­ing the X11-based stan­dard graph­ics server.

In­put con­fi­den­tial­ity is lim­ited as it is pos­si­ble for any X11 client to snoop on the key­board in­puts and mouse po­si­tion, but not mouse click events or wheel scrolling (src).

The only se­cu­rity prop­erty that can truly be fixed on X11 is the in­tegrity of ap­pli­ca­tion’s out­put graphic buffers (the im­age of the ap­pli­ca­tion that is dis­played on the screen). This work re­quires ap­pli­ca­tions to share buffers with the x-server us­ing DMA-Buf in­stead of GEM’s buffer shar­ing mech­a­nism which has very lim­ited ac­cess con­trol. GEM is the ker­nel in­ter­face for open source dri­vers to al­lo­cate graphic buffers and al­low ap­pli­ca­tions to share them.

Fix­ing the other se­cu­rity prop­er­ties is im­pos­si­ble us­ing the X11 pro­to­col as it would break too many le­git­i­mate ap­pli­ca­tions that rely on those fea­tures. Dis­abling ac­cess to these fea­tures would ef­fec­tively make the X-Server non-com­pli­ant with the X11 pro­to­col. Only au­tho­ris­ing the le­git­i­mate ap­pli­ca­tions to ac­cess those re­stricted in­ter­faces wouldn’t in­crease the se­cu­rity of the sys­tem ei­ther be­cause of the amount of ap­pli­ca­tions who do re­quire them. As there is a new graph­ics server emerg­ing, we have de­cided to fix this one and not re­peat X’s mis­takes. In sum­mary, this is where the graph­ics stack se­cu­rity cur­rently stands:

+-----------------+---------+----------+
|    Property     |  Input  |  Output  |
+-----------------+---------+----------+
| Confidentiality |   NO    |    NO    |
|    Integrity    |   NO    |    WIP   |
|  Availability   |   NO    |    NO    |
+-----------------+---------+----------+

3. Way­land

Way­land is in­tended as a sim­pler re­place­ment for X, eas­ier to de­velop and main­tain. GNOME and KDE are ex­pected to be ported to it.

Way­land is a pro­to­col for a com­pos­i­tor to talk to its clients as well as a C li­brary im­ple­men­ta­tion of that pro­to­col. The com­pos­i­tor can be a stand­alone dis­play server run­ning on Linux ker­nel mod­e­set­ting and evdev in­put de­vices, an X ap­pli­ca­tion, or a Way­land client it­self. The clients can be tra­di­tional ap­pli­ca­tions, X servers (root­less or fullscreen) or other dis­play servers.

Source

Cur­rent state of se­cu­rity within Way­land com­pos­i­tors

The first good point of the Way­land pro­to­col is in­put man­age­ment. At the mo­ment, the pro­to­col doesn’t al­low snoop­ing on the in­put (con­fi­den­tial­ity), gen­er­at­ing in­put events (in­tegrity) nor for an ap­pli­ca­tion to grab all events (avail­abil­ity). How­ever, Way­land clients al­low­ing LD_PRELOAD are still vul­ner­a­ble to in­put at­tacks, as demon­strated by Maarten Baert. This is not Way­land com­pos­i­tors’ prob­lem so it won’t be taken into ac­count in this dis­cus­sion.

Just like with X, there are mul­ti­ple ways for ap­pli­ca­tions to send their out­put buffers to the graph­ics server. With Way­land/We­ston, ap­pli­ca­tions can use shared mem­ory (SHM) or GEM’s buffer shar­ing mech­a­nism. SHM buffer shar­ing is meant for CPU-ren­dered ap­pli­ca­tion while GEM-based buffer shar­ing is meant for GPU-ren­dered ap­pli­ca­tions.

SHM buffer shar­ing seems to be us­ing anony­mous files and file de­scrip­tor(fd) pass­ing in or­der to trans­mit buffers from the client to the com­pos­i­tor. This makes sure that only the cre­ator and the re­ceiver of the fd can ac­cess the (now-shared) re­source, mak­ing it im­pos­si­ble for a third-party other than the ker­nel to spy on or mod­ify the out­put of other ap­pli­ca­tions (con­fused-deputy). Con­fi­den­tial­ity and in­tegrity seems to be guar­an­teed but I haven’t dwelved into the im­ple­men­ta­tion to make sure of it.

GEM buffer shar­ing is known to be in­se­cure be­cause shared buffers are ref­er­enced by a eas­ily-guess­able 32-bit han­dle. Once the han­dle is guessed, the buffer can be opened by other ap­pli­ca­tion run by the same user with­out ac­cess con­trol. Once opened, the buffers may be read from or writ­ten into. This means con­fi­den­tial­ity or in­tegrity can­not be guar­an­teed on the out­put of ap­pli­ca­tions us­ing this buffer-shar­ing method.

On-go­ing work is be­ing per­formed to make use of DMA-Buf in­stead of GEM. DMA-Buf, just like SHM, is based on anony­mous files and fd-pass­ing and even al­lows dif­fer­ent GPU dri­vers to ex­change GPU buffers. Once the Way­land pro­to­col and GPU ap­pli­ca­tions start us­ing it, con­fi­den­tial­ity and in­tegrity of the out­put buffers won’t be a prob­lem any­more.

+-----------------+---------+----------+
|    Property     |  Input  |  Output  |
+-----------------+---------+----------+
| Confidentiality |   YES   |   YES*   |
|    Integrity    |   YES   |   YES*   |
|  Availability   |   YES   |   YES    |
+-----------------+---------+----------+

2014/02/21 UP­DATE: Kris­t­ian Høgs­berg pointed out in the com­ments that Way­land’s EGL code in mesa has sup­ported DMA-BUF for quite a while al­though it was made se­cure in mesa 10.0 (con­fi­den­tial­ity & in­tegrity). I up­dated the table above to re­fect on that.

The need for stan­dard­ised priv­i­leged in­ter­faces

Al­though Tim and I ad­vised Way­land com­pos­i­tors not to rely on ex­ter­nal pro­grams to per­form priv­i­leged tasks, some peo­ple do think it is needed as they want to make it pos­si­ble to de­velop cross-com­pos­i­tors ap­pli­ca­tions per­form­ing priv­i­leged tasks. Ex­am­ples of such ap­pli­ca­tions would be:

• Screen­shot ap­pli­ca­tions (stills and video)
• Vir­tual key­boards and point­ing de­vices
• Screen shar­ing (VPN, Skype)
• Hotkeys han­dlers (?)
• Ses­sion lock­ers

All of these ap­pli­ca­tions are vi­o­lat­ing one or more se­cu­rity prop­er­ties. Way­land com­pos­i­tors should thus con­trol the ac­cess to the in­ter­faces al­low­ing those ap­pli­ca­tions to work. Since we want these ap­pli­ca­tions to be cross-com­pos­i­tors, a stan­dard­ised way of grant­ing/pass­ing/re­vok­ing priv­i­leges should be de­scribed in the pro­to­col or its im­ple­men­ta­tion ref­er­ence guide.

Al­low­ing the user to se­curely break se­cu­rity prop­er­ties

By de­fault, the sys­tem should be en­forc­ing all the se­cu­rity prop­er­ties we de­fined ear­lier. How­ever, some­times, users need/want to au­to­mate some process, record their screens or lock the com­puter with a cus­tom-app. This is why we need ways to by-pass the se­cu­rity when it is re­ally needed. With­out such means, peo­ple may refuse to use Way­land be­cause it “takes free­dom away from them”. How­ever an ideal de­sign is so that some­one will al­ways come up first with the “right” way to do some­thing. Here when it comes to dis­trib­u­tors/ven­dors us­ing Way­land, you want them to use your own pre­ferred se­cu­rity prop­erty rather than en­tirely un­lock­ing Way­land’s safe­guards to sup­port the fea­tures of poorly-writ­ten apps.

The usual way of deal­ing with ap­pli­ca­tions need­ing more priv­i­leges is to sta­t­i­cally give them at launch time. Once an ap­pli­ca­tion has no use of the per­mis­sion any­more, it can re­voke its right to ac­cess it, un­til its next ex­e­cu­tion. This is very sim­i­lar to what ex­ists with ca­pa­bil­i­ties.

The prob­lem with such a sys­tem is that a ma­li­cious ap­pli­ca­tion could po­ten­tially take ad­van­tage of a poorly-coded ap­pli­ca­tion that holds an in­ter­est­ing ca­pa­bil­ity (as­signed sta­t­i­cally at launch time), and use that ap­pli­ca­tion’s ca­pa­bil­ity to gain in­di­rect ac­cess to the re­stricted in­ter­face it is in­ter­ested in. This is be­cause per­mis­sions aren’t granted ac­cord­ing to the im­me­di­ate in­tent of the user. In­deed, a user would ide­ally al­ways have a way to be aware of a re­duced se­cu­rity state. This means the user has to take ac­tion in or­der to tem­po­rary re­duce the se­cu­rity. The user should then be able to check whether the sys­tem’s se­cu­rity is still re­duced and should be able to re­voke per­mis­sions. Cap­tur­ing the user’s in­tent can be done by:

• Wait­ing for a user to press the key with a clear se­man­tic be­fore launch­ing the as­so­ci­ated ap­pli­ca­tion (for in­stance, PrintScreen launch­ing the screen-shot ap­pli­ca­tion)
• Prompt­ing the user when­ever an ap­pli­ca­tion tries to ac­cess a re­stricted in­ter­face
• Cre­at­ing se­cure wid­gets that are drawn and man­aged by the com­pos­i­tor but can be im­ported in ap­pli­ca­tions (UDAC)
• Any other way?

The first so­lu­tion re­quires ab­solute trust in the in­put in­tegrity and re­quires the com­pos­i­tor to know which ap­pli­ca­tion it should run (full­path to the bi­nary). The sec­ond so­lu­tion re­quires both trust in in­put in­tegrity and out­put in­tegrity (to pre­vent a ma­li­cious ap­pli­ca­tion from chang­ing the con­tent of the prompt win­dow to change its se­man­tic and turn it into a fake ad­ver­tise­ment, for in­stance). The third so­lu­tion re­quires se­cure wid­gets, un­for­tu­nately it is -ENOTQUITETH­EREYET. We have ideas on how to im­ple­ment them us­ing sub-sur­faces, they will be dis­cussed again later on this very same blog ;)

While I think the user-in­tent method has a higher se­cu­rity than sta­tic priv­i­lege assig­na­tion, I think both should be im­ple­mented with the lat­ter used as a way for users to spec­ify they are OK with po­ten­tially re­duc­ing the se­cu­rity of the desk­top en­vi­ron­ment to let the ap­pli­ca­tion he/she wants to run prop­erly. This will lower users’ dis­sat­is­fac­tion and should re­sult in a bet­ter se­cu­rity than by­pass­ing some se­cu­rity prop­er­ties for all ap­pli­ca­tions. I am how­ever wor­ried that some stu­pid ap­pli­ca­tions may be OK with cre­at­ing snap­shot ca­pa­bil­i­ties from the com­mand line, with­out re­quir­ing the user’s in­put. A pack­ager would then grant the priv­i­leges to this ap­pli­ca­tion by de­fault and thus, the mere fact of hav­ing this ap­pli­ca­tion in­stalled will make your desk­top non-con­fi­den­tial any­more.

This is why once priv­i­leges have been granted, the user needs to have a way to keep track of who has ac­cess to re­stricted in­ter­faces. This can be done by hav­ing a manda­tory no­ti­fi­ca­tion when an ap­pli­ca­tion ac­cesses a priv­i­leged in­ter­face and a com­pos­i­tor-owned ap­pli­ca­tion in the systray whose colour would in­di­cate the cur­rent se­cu­rity state (no threat, at least one ap­pli­ca­tion has the rights to use a re­stricted in­ter­face and at least one ap­pli­ca­tion is us­ing a re­stricted in­ter­face). A click on this icon could pro­vide more in­for­ma­tion about which re­stricted in­ter­faces are used by which ap­pli­ca­tion. A but­ton could then be added to each en­try to al­low users to re­voke some priv­i­leges of ap­pli­ca­tions. While I think the in­ter­face for the ap­pli­ca­tion pro­vid­ing this feed­back should be spec­i­fied, the user shouldn’t have a choice on it and it should be hard­coded in the Desk­top En­vi­ron­ment.

Rec­om­men­da­tions to re­stricted Way­land in­ter­face de­sign­ers

I have never de­signed an in­ter­face for Way­land and don’t know what the best prac­tice is. How­ever, I know that re­stricted in­ter­faces should never be con­sid­ered as al­ways us­able.

The first im­por­tant point is that be­fore be­ing able to use an in­ter­face, a client should first bind to it. This bind­ing process could ei­ther suc­ceed or fail, de­pend­ing on the com­pos­i­tor’s se­cu­rity pol­icy. Clients are man­dated to test that bind­ing worked well be­fore us­ing the in­ter­face. In case it didn’t, clients should fail grace­fully and tell the user what re­stricted in­ter­face couldn’t be bound. Also, bind­ing a re­stricted in­ter­face could take some time and the ap­pli­ca­tion shouldn’t block on it.

To sup­port priv­i­leges re­vo­ca­tion, a re­voke sig­nal should be added to the in­ter­face in or­der to in­form clients their rights to ac­cess the re­stricted in­ter­face have been re­voked. Clients should fall­back grace­fully and tell the user they re­ceived such a sig­nal.

Launch­ing priv­i­leged Way­land clients from the com­pos­i­tor

The most-se­cure way of launch­ing clients re­quir­ing re­stricted in­ter­faces is to let the com­pos­i­tor run them by it­self. This way, it can con­trol the en­vi­ron­ment in which the process has been launched which low­ers the risks of en­vi­ron­ment at­tacks such as the LD_PRELOAD one ex­posed ear­lier.

Im­ple­ment­ing such a sys­tem is dif­fi­cult as the com­pos­i­tor needs to re­mem­ber that the PID of the client it launched should be granted the priv­i­leges to ac­cess one or more re­stricted in­ter­faces when this (soon-to-be­come)client con­nects to the Way­land com­pos­i­tor. Not only does it mean that the com­pos­i­tor needs to have a sep­a­rate table of which PIDs are sup­posed to get which priv­i­leges, it also means the com­pos­i­tor needs to keep track of the death of the client’s PID to avoid an­other process from re-us­ing the PID of this client and gain­ing ac­cess to priv­i­leged in­ter­faces it wasn’t sup­posed to ac­cess.

A sim­pler and more se­cure so­lu­tion would be for the com­pos­i­tor to open a UNIX socket to it­self be­fore exec’ing the client. Once opened, it should be sim­pler for the com­pos­i­tor to set the client’s ca­pa­bil­i­ties to a flag stored in the struc­ture track­ing the client and then ex­e­cute the client’s bi­nary. When run­ning the exec() syscall, all the FDs that have not been opened with the O_CLOEXEC flag will be passed on to the new process. A run-time pa­ra­me­ter of the Way­land client could then be used to tell which FD rep­re­sents the unix socket to the Way­land com­pos­i­tor. An ex­am­ple of such pa­ra­me­ter could be --wayland-fd=xxx. The com­pos­i­tor should how­ever be care­ful it doesn’t leak any un-needed FD to the new client.

2014/02/21 UP­DATE: Pekka Paala­nen said on the Way­land Mail­ing List the lat­ter ap­proach is al­ready im­ple­mented in Way­land and sug­gested read­ing the doc­u­men­ta­tion about the en­vi­ron­ment vari­able WAYLAND_SOCKET in wl_dis­play_­con­nect. I ac­tu­ally pre­fer the im­ple­mented so­lu­tion bet­ter be­cause it is trans­par­ent to ap­pli­ca­tions. Well done!

Let­ting ap­pli­ca­tions re­quire more priv­i­leges at run time

Some times, ap­pli­ca­tion may re­quire ac­cess to a re­stricted in­ter­face af­ter it has been launched. In this case, they can use the bind­ing call I de­scribed ear­lier and the com­pos­i­tor will grant ac­cess to it or not, de­pend­ing on its con­fig­u­ra­tion or pol­icy.

The prob­lem with al­low­ing ap­pli­ca­tions to re­quire more priv­i­leges is that we do not con­trol their en­vi­ron­ment and we can­not make sure it didn’t get loaded with LD_PRELOAD or tam­pered with in any other way. As this de­ci­sion re­ally de­pends on which other se­cu­rity tools are be­ing used on the com­puter, this isn’t some­thing Way­land com­pos­i­tors should hard-code. This leads us to our fi­nal pro­posal.

Way­land Se­cu­rity Mod­ules

As seen ear­lier, grant­ing ac­cess to a re­stricted in­ter­face or not de­pends on the con­text of the client (how it was launched, pre­vi­ous ac­tions). The ex­pected be­hav­iour should be de­fined by a se­cu­rity pol­icy.

As no con­sen­sus on the pol­icy can ap­par­ently be reached (as usual in se­cu­rity), we have all agreed that we needed to sep­a­rate the pol­icy from the code. This is very much alike Linux Se­cu­rity Mod­ules (LSM) or X Ac­cess Con­trol Ex­ten­sion (XACE).

From a soft­ware en­gi­neer­ing point of view, we would work on a se­cu­rity li­brary called Way­land Se­cu­rity Mod­ules (name sub­ject to changes) that Way­land com­pos­i­tors would call when a se­cu­rity de­ci­sion would need to be made. The li­brary would then load the wanted se­cu­rity pol­icy, de­fined by a shared-ob­ject that I will re­fer to as the se­cu­rity back­end. In the case of al­low­ing a client to bind a re­stricted in­ter­face or not, the cor­re­spond­ing WSM hook should re­turn ACCEPT, PROMPT or DENY, prompt mean­ing the com­pos­i­tor would have to ask the user if he wants to ac­cept the risk or not. Let me stress out that prompt­ing should be a last-re­sort mea­sure as nu­mer­ous stud­ies have been made prov­ing that un­less asked very rarely, users will al­ways al­low the op­er­a­tion.

Some ad­di­tional hooks would also be needed in or­der to track the state of Way­land clients (open, close, etc…) but noth­ing too ma­jor should be needed. The com­pos­i­tors would just have to store this con­text in a void *security; at­tribute in the Way­land client struc­ture. Fi­nally, WSM could be ex­tended to con­trol the ac­cess to the clip­board and maybe other in­ter­faces I haven’t thought about yet.

The de­sign of this li­brary has not started yet. If you are in­ter­ested in help­ing out, I would love to have some feed­back on what are your use cases for WSM.

POSIX se­cu­rity back­end

Most users run their com­put­ers with­out Manda­tory Ac­cess Con­trol (MAC), it is thus im­por­tant to pro­vide the best se­cu­rity pos­si­ble by de­fault. The POSIX se­cu­rity back­end shouldn’t de­pend on any de­ci­sion en­gine or MAC sys­tem (such as SELinux, To­moyo, Ap­pAr­mor, …) and should be easy to con­fig­ure.

2014/02/21 UP­DATE: A reader on red­dit said the fol­low­ing about the above para­graph: “Pretty weird state­ment con­sid­er­ing both Ubuntu and Fe­dora sev­eral other dis­tros come with MACs en­abled by de­fault”. As far as I know, no user-ori­ented op­er­at­ing sys­tems has a MAC pol­icy for graph­i­cal ap­pli­ca­tions. Both Ubuntu and Fe­dora run ap­pli­ca­tions un­con­fined. The only sys­tem I know about that has a real MAC pol­icy for all its ap­pli­ca­tions (and many more se­cu­rity lay­ers) is PIGA-OS, a re­search op­er­at­ing sys­tem I helped de­vel­op­ping at the ENSI de Bourges.

A de­fault pol­icy could be spec­i­fied in /etc/wayland/security.conf. Per-client con­fig­u­ra­tion could be stored in /etc/wayland/authorized_clients.d/. This would al­low pack­age man­agers to in­stall ap­pli­ca­tion se­cu­rity poli­cies along with the ap­pli­ca­tion. Each ap­pli­ca­tion-spe­cific pol­icy would de­fine the full path of the al­lowed bi­nary and which re­stricted in­ter­face the ap­pli­ca­tion needs to get ac­cess to and in which cases is it ac­cept­able (only when run by the com­pos­i­tor? etc…). This is en­ables Trusted Path Ex­e­cu­tion (TPE) as only the bi­nary spec­i­fied by the full­path will match this set of priv­i­leges.

Dif­fer­ent UNIX users should be al­lowed to have dif­fer­ent se­cu­rity pa­ra­me­ters. The eas­i­est way would be to store per-user con­fig­u­ra­tion in dif­fer­ent files in /etc/wayland/users.d/ in or­der to sim­plify the logic. An­other pos­si­bil­ity would be to have ~/.wayland/ over­rid­ing the /etc/wayland/ con­fig­u­ra­tion folder. The lat­ter so­lu­tion would be harder to im­ple­ment se­curely be­cause only the com­pos­i­tor should be al­lowed to change the con­fig­u­ra­tion.

In any case, to be con­sid­ered valid, con­fig­u­ra­tion files should all be root-owned and 644 to pre­vent ma­li­cious ap­pli­ca­tions from chang­ing the se­cu­rity pol­icy. This means chang­ing the se­cu­rity pol­icy will be con­sid­ered as an ad­min­is­tra­tive task which sounds about right.

Other se­cu­rity back­ends?

Other se­cu­rity back­ends could be im­ple­mented/in­te­grated with PAM, Polkit or SELinux. You could even write your own se­cu­rity back­end with­out need­ing to patch any Way­land com­pos­i­tor, un­less you need new WSM hooks.

Please let me know about what se­cu­rity back­end you would be in­ter­ested in!

4. Ac­knowl­edg­ment

This ar­ti­cle is the re­sult of count­less hours of dis­cus­sions with my friends Tim­othée Ravier and Steve Dodier-Lazaro. It is also the re­sult of mul­ti­ple dis­cus­sions with Se­bas­t­ian Wick and Maarten Baert on Way­land’s mail­ing list (lat­est thread).

5. Con­clu­sion

This ar­ti­cle is just a sum­mary of the cur­rent sit­u­a­tion we are in se­cu­rity-wise and a sum­mary of all the dis­cus­sions I have been in­volved in. My hope is to get some feed­back from the Way­land and se­cu­rity com­mu­ni­ties in or­der to achieve a se­cure sys­tem with cross-com­pos­i­tor priv­i­leged ap­pli­ca­tions!

Please send me some feed­back, I would love to hear from you!