1. In­tro­duc­tion

Af­ter Mar­tin pub­lished his ar­ti­cle on the se­cu­rity on Way­land, we re­ceived plenty of feed­back, and among it emerged a dis­cus­sion on the dif­fi­culty of pre­vent­ing the spoof­ing of au­then­ti­ca­tion and au­tho­ri­sa­tion di­alogs (the for­mer of­ten be­ing used as a by-prod­uct for the lat­ter). Such di­alogs ap­pear ei­ther when you re­quire a priv­i­lege es­ca­la­tion (gksu-like) or ac­cess to a re­stricted/priv­i­leged in­ter­face con­trolled by the com­pos­i­tor/desk­top en­vi­ron­ment. In the sys­tem we en­vi­sion, ap­pli­ca­tions have re­stricted priv­i­leges and some are awarded spe­cial ones (such as the abil­ity to record the screen, re­ceive spe­cial key­board in­put, etc.). When an app needs a priv­i­lege it does not nat­u­rally have, it must ask for it through an au­tho­ri­sa­tion pro­to­col. Be­sides, we also need to pro­vide a means of au­then­ti­ca­tion that re­sists spoof­ing, for the few cases where au­then­ti­ca­tion re­mains nec­es­sary. In this ar­ti­cle, I ex­plore the threat model, se­cu­rity re­quire­ments and de­sign op­tions for us­able and se­cure au­tho­ri­sa­tion and au­then­ti­ca­tion on mod­ern Linux.

Er­rata: this ar­ti­cle is not about when to use au­tho­ri­sa­tion, but about how to de­sign it. I per­fectly con­cur to the view that the best per­mis­sion re­quest is the one that does not in­volve dis­turb­ing the user! The ideas dis­cussed here ap­ply for those few edge cases where we may not be able to de­sign au­tho­ri­sa­tion re­quests away (up­dated on 2014-03-28).

2. State of the Art

Linux

Au­then­ti­ca­tion: Most of the time, a user will be asked to au­then­ti­cate by a polkit au­then­ti­ca­tion agent, when try­ing to per­form an op­er­a­tion that re­quires an­other ac­count’s cre­den­tials. Polkit is quite para­doxal to me, be­ing de­scribed as pro­vid­ing an “au­tho­ri­sa­tion API” yet only know­ing how to ask users to au­then­ti­cate rather than au­tho­rise. Other forms of au­then­ti­ca­tion in­clude graph­i­cal front-ends to su (KdeSu and gksu) which al­low run­ning com­mands with a dif­fer­ent iden­tity than one al­ready has.

Au­tho­ri­sa­tion: At the mo­ment, very few sit­u­a­tions trig­ger proper au­tho­ri­sa­tion di­alogs on Linux sys­tems. polkitd seems to be the au­tho­ri­sa­tion API of choice, and it maps re­quested priv­i­leged op­er­a­tions a user’s UNIX per­mis­sions and a sys­tem-wide pol­icy. Hence, polkitd would ei­ther di­rectly au­tho­rise an op­er­a­tion, or it will ask the user to au­then­ti­cate as some­one else who has the re­quested priv­i­leges. With Mar­tin’s pro­posal on Way­land se­cu­rity, we seek to in­tro­duce some forms of ca­pa­bil­i­ties in user­land which would cre­ate process au­tho­ri­sa­tion use cases, though.

Here are some ex­am­ples of com­monly-faced au­then­ti­ca­tion di­alogs on Linux nowa­days (and the only au­tho­ri­sa­tion di­a­log I could find). As far as I could bother to check, BSD flavours also use polkitd.

• 
• 
• 
• 
• 
• 
• 

Mi­crosoft Win­dows

Win­dows uses a sin­gle in­ter­face for au­tho­ri­sa­tion since Vista, which is named User Ac­count Con­trol (UAC). De­spite its bad rep­u­ta­tion and a cou­ple of glitches and se­cu­rity flaws, a bit of scrutiny into the is­sues sur­round­ing priv­i­lege au­tho­ri­sa­tions con­vinced me that Mi­crosoft’s de­ci­sion to setup UAC is pretty good (the im­ple­men­ta­tion / se­cu­rity ben­e­fits not so, as pointed out here or there – read the com­ments too). I’m hop­ing that we can do even bet­ter than them by learn­ing from the at­tacks on UAC and from the rea­sons that push Win­dows users to dis­able it.

UAC is an API that ap­pli­ca­tions must use in or­der to de­clare which priv­i­leges they re­quire or to ask for ex­tra priv­i­leges. Ap­pli­ca­tions start with rel­a­tively low priv­i­leges, even when the user run­ning them is an ad­min­is­tra­tor. Only some apps signed by Mi­crosoft it­self can run on ad­min­is­tra­tor priv­i­leges by de­fault. Most apps run with “medium” priv­i­leges and they can even drop some if they feel they are at risk of be­ing ex­ploited (hence re­duc­ing the im­pact they can have on oth­ers). This is com­monly done by Web browsers.

When apps re­quire a user in­ter­ven­tion to ac­quire a new priv­i­lege or to run, the user is ei­ther prompted to au­tho­rise the re­quest or to au­then­ti­cate as an ad­min­is­tra­tor with suf­fi­cient per­mis­sions (note also the con­fig­u­ra­tion op­tion that re­quires an ad­min­is­tra­tor to re-au­then­ti­cate be­fore the au­tho­ri­sa­tion is granted). The in­ter­face for all these re­quests con­sists of a dim back­ground be­ing ap­plied to the cur­rent desk­top, and a modal di­a­log – com­pletely iso­lated and pro­tected from other ap­pli­ca­tions – ap­pear­ing and wait­ing for the user to in­put her in­for­ma­tion/de­ci­sion. The di­a­log pre­sents in­for­ma­tion on the iden­tity of the app (some­times as lit­tle as the ex­e­cutable name, which is not very in­for­ma­tive) and the name of its pub­lisher (with dif­fer­ent dec­o­ra­tions and icons be­ing used to em­pha­size whether the user should trust that pub­lisher in­for­ma­tion or not, from signed Mi­crosoft soft­ware to un­known pub­lish­ers’ soft­ware).

The topic of this post is Linux so I won’t dis­cuss this fur­ther, but note that any app can ap­par­ently im­i­tate this UAC di­a­log’s look (ex­am­ple with KeeP­ass).

• 
• 
• 
• 

Ap­ple OS X

Al­beit very in­ter­est­ing, OS X’s au­tho­ri­sa­tion sys­tem is not dis­cussed be­cause of the out­ra­geous terms of use of their web­site, cov­er­ing the doc­u­men­ta­tion I wanted to cite (see point 3.b of this doc­u­ment).

Let us just note the fol­low­ing:

• apps need to get the user to re-au­then­ti­cate through a third-party dae­mon to per­form priv­i­leged op­er­a­tions
• apps can check whether the user will need to au­tho­rise them for cer­tain op­er­a­tions, so they can re­flect their lack of au­thor­ity in their GUI (use­ful for sys­tem set­tings)
• spoof­ing at­tacks on the con­tent of the au­tho­ri­sa­tion di­a­log are (or were at least in the past) greatly fa­cil­i­tated by the API

3. Priv­i­leges in a Way­land-Based Linux

Mar­tin has pre­sented a list of re­stricted priv­i­leged in­ter­faces that could re­quire an ap­pli­ca­tion to re­quest an au­tho­ri­sa­tion in his Way­land ar­ti­cle. My list is a bit dif­fer­ent be­cause I’d in­clude priv­i­leges un­re­lated to Way­land / win­dowed ap­pli­ca­tions. The rea­son is be­cause con­sis­tency of UIs is a very im­por­tant el­e­ment of the se­cu­rity men­tal model of the user: if they are used to see­ing the same UI all the time, they will be more sus­pi­cious of spoof­ing at­tacks (cf. Sec­tion 4). Some typ­i­cal priv­i­leges that re­quire au­tho­ri­sa­tion:

• Screen­shot tak­ing and screen record­ing
• Screen shar­ing (VPN, Skype) – pos­si­bly iden­ti­cal to the one above
• Vir­tual key­boards and point­ing de­vices
• Au­dio (mi­cro­phone, am­pli­fier) and video (we­b­cam, CCTV) cap­ture de­vices
• Bind­ing to spe­cific key­board short­cuts one does not own
• Clip­board man­age­ment
• Ac­cess to data in app-spe­cific pass­word stores in the user’s keyring
• Abil­ity to run with­out a GUI (off-topic, com­ing in a later ar­ti­cle)

I don’t in­clude in­ter­faces that ac­tu­ally re­quire au­then­ti­ca­tion rather than just au­tho­ri­sa­tion, though I’ll try to dis­cuss the co­hab­i­ta­tion be­tween the two mech­a­nisms. These in­ter­faces show the need for both a within-ses­sion au­then­ti­ca­tion UI (e.g., gksu) and a cross-ses­sions au­then­ti­ca­tion UI (the DM’s greeter). Gen­er­ally speak­ing, one may ei­ther need to pro­vide cre­den­tials for an ad­min­is­tra­tor’s ac­count, the root ac­count, or her own ac­count (only when it’s le­git­i­mate to in­clude phys­i­cal ad­ver­saries in the threat model):

• In­stalling ap­pli­ca­tions (auth as ad­min)
• Man­ag­ing users (auth as ad­min)
• Con­fig­ur­ing sys­tem-wide set­tings (auth as ad­min)
• Chang­ing one’s own pass­word (re­quires re-auth, se­cu­rity best prac­tice)
• Ses­sion lock­ing (re­quires re-auth from within the greeter)

To sum up, we want to man­age three cat­e­gories of in­ter­ac­tions: a user au­tho­ris­ing a process, a user au­then­ti­cat­ing as some­one else to bor­row their priv­i­leges, and a user re-au­then­ti­cat­ing. It’s im­por­tant to come up with a sin­gle way to graph­i­cally do all those things, be­cause con­sis­tency is a key to mak­ing users dif­fer­en­ti­ate the sys­tem’s UI from those of ma­li­cious ap­pli­ca­tions. I would love to see a sys­tem pre­sent­ing the fol­low­ing sim­ple motto to the user: “We will ask you to type your own pass­word only when you change it. We will ask you to type an ad­min­is­tra­tor’s pass­word only when you man­age sys­tem-wide set­tings.”

Er­rata: I would like to clar­ify that priv­i­lege grant­ing, in my view, should be done through three se­quen­tial processes and not sys­tem­at­i­cally through au­tho­ri­sa­tion UIs:

• de­fault sys­tem-wide lists of priv­i­leged apps (main­tained by DEs and by dis­trib­u­tors), which can be cus­tomised by users
• ev­i­dence of user in­tent (e.g., Se­cu­rity by Des­ig­na­tion or User-Dri­ven AC)
• when none of the above works, au­tho­ri­sa­tion prompts (to pro­vide a sit­u­ated way to man­age se­cu­rity for un­trusted apps or un­com­mon use cases)

(up­dated on 2014-03-28).

4. Threat Model

A nor­mal threat model would in­clude a jus­ti­fi­ca­tion why cer­tain ad­ver­saries ex­ist and a clear view of their ca­pa­bil­i­ties. When de­sign­ing gen­eral-pur­pose op­er­at­ing sys­tems, we can only con­sider gen­eral ad­ver­saries with gen­eral ca­pa­bil­i­ties. We need to de­cide what ad­ver­saries we de­sign against and which are not our re­spon­si­bil­ity’s but that of the peo­ple de­ploy­ing our sys­tem.

Here, we con­sider any ad­ver­sary able to re­motely ex­e­cute code with the user’s priv­i­leges. For in­stance, an ap­pli­ca­tion may turn out to be ma­li­cious, or it may be par­tially or en­tirely con­trolled by an ad­ver­sary through some crafted in­put fed into it by the user. An ad­ver­sary may be very in­ter­ested in ei­ther of ob­tain­ing re­stricted priv­i­leges (for what­ever rea­son) or steal­ing au­then­ti­ca­tion cre­den­tials typ­i­cally used to grant such priv­i­leges.

Snoop­ing/Spy­ing on au­then­ti­ca­tion di­alogs (theft of cre­den­tials)

Very very few peo­ple are aware of this, but the cur­rent dis­play server X11 does not pro­vide any iso­la­tion be­tween the in­put events of var­i­ous ap­pli­ca­tions (which in it­self is a suf­fi­cient ar­gu­ment in favour of the de­vel­op­ment and adop­tion of Way­land). You can eas­ily find tu­to­ri­als on how to snoop pass­words from other win­dowed ap­pli­ca­tions in­clud­ing su/sudo util­i­ties in­side a Ter­mi­nal app. This al­lows steal­ing cre­den­tials from any au­then­ti­ca­tion di­a­log that the user runs. As ex­plained by Mar­tin, this will be pre­vented by de­sign in Way­land com­pos­i­tors.

In­ject­ing in­put into auth di­alogs (theft of priv­i­leges)

An­other thing that is pos­si­ble with X11 is to in­ject key­board/mouse in­put into other win­dowed ap­pli­ca­tions (ex­am­ple). At­tacks to util­i­ties like gksu or kdesu are very easy to per­form and can be so­phis­ti­cated to the point of be­ing barely no­tice­able by at­ten­tive users.

One may for in­stance per­form a tim­ing at­tack to in­ject their own bi­nary name in­stead of the one typed in by the user. This can be slightly mit­i­gated by dis­play­ing the full path of the com­mand to be ex­e­cuted and let­ting the user read it be­fore au­then­ti­cat­ing. It can also be en­tirely mit­i­gated by not let­ting un­priv­i­leged apps in­ject key­board events into oth­ers’ win­dows.

At­tack­ers may also in­voke any au­tho­ri­sa­tion API them­selves and in­ject mouse events to click on the “Au­tho­rise” but­ton of the au­tho­ri­sa­tion di­a­log on be­half of the user. There are some hacks to pro­tect against this such as ran­dom­iz­ing the start­ing po­si­tion of the mouse cur­sor, di­a­log and di­a­log con­tents, etc. How­ever, the only one proper so­lu­tion to this prob­lem is mak­ing sure that no un­priv­i­leged ap­pli­ca­tion can in­ject mouse events.

I wrote a sim­ple proof-of-con­cept that in­jects a pre­fix to the path of a com­mand when in­vok­ing gksu. To use it, you need to time it so that the events are in­serted af­ter the user typed the com­mand and be­fore they type Re­turn, lead­ing to the ex­e­cu­tion of ma­li­cious /tmp/myscript.sh rather than be­nign /usr/bin/myscript.sh. Note that this is not a gksu vul­ner­a­bil­ity but a X11 one. If the user called gksu myscript.sh in­stead, I’d just need to move the cur­sor in be­tween gksu and its ar­gu­ment and then in­ject the pre­fix that runs my own mal­ware. If I don’t know the name of the in­voked bi­nary, I could re­place it rather than prepend it.

These at­tacks are also pre­vented by de­sign in Way­land.

Con­fused deputy (theft of priv­i­leges)

I’m just giv­ing some ex­am­ples on Win­dows Vista and 7 here be­cause it’s a bit of a larger is­sue than the graphic stack’s role in UI de­sign.

• Win­dows 7 UAC: the user could feed their own li­brary to a sys­tem util­ity, which was white-listed for UAC; The li­brary could then per­form au­tho­ri­sa­tion queries with the iden­tity of that sys­tem util­ity and skip au­then­ti­ca­tion (link)
• Win­dows Vista UIPI: apps can list win­dows cur­rently open to find which priv­i­leged processes to con­tact for con­fused deputy at­tacks (link)

Con­clu­sion: we must keep track of which apps pos­sess priv­i­leges and hide them from un­priv­i­leged apps, in a sys­tem­atic way. The mat­ter is not dis­cussed in this ar­ti­cle, but com­ments and ideas are very wel­come.

Spoof­ing di­a­log UIs (theft of cre­den­tials)

This is in my view the hard­est at­tack to pre­vent. Spoof­ing oc­curs when a third-party ap­pli­ca­tion im­i­tates the ap­pear­ance of an auth di­a­log in or­der to cause the user to in­ter­act with it as they would with the real di­a­log. If you spoof an au­tho­ri­sa­tion di­a­log, then you will ob­tain noth­ing as the user “au­tho­ris­ing” your re­quest on a spoofed di­a­log will not lead you to re­ceiv­ing the cor­re­spond­ing priv­i­lege from the sys­tem. Au­tho­ri­sa­tion spoof­ing is at best an­noy­ing noise for the user, noth­ing that con­cerns the Way­land pro­to­col.

How­ever, au­then­ti­ca­tion spoof­ing has very dra­matic con­se­quences: if a spoof gets the user to type in their real cre­den­tials, those can be used to log into the user’s ses­sion or even else­where (be­cause of our propen­sity to reuse cre­den­tials when­ever pos­si­ble). Pro­tect­ing against spoof­ing is only pos­si­ble by craft­ing a UI that can­not be en­tirely imited (I’ll pre­sent Mar­tin’s ideas on that be­low).

How­ever, what re­ally mat­ters is the abil­ity of the user to sys­tem­at­i­cally and im­me­di­ately dis­tin­guish any fake from the true UI and to as­so­ci­ate the fake with a strong feel­ing of in­se­cu­rity. Oth­er­wise, spoof­ing may very well still oc­cur. The so­lu­tion to this is to have the au­then­ti­ca­tion di­a­log au­then­ti­cate it­self to the user by pre­sent­ing a se­cret/cre­den­tial shared with the user (thanks to GaMa for in­spir­ing this re­quire­ment). The se­cret should be used for that pur­pose, and not be one that is used to au­then­ti­cate the user as this would al­low shoul­der surf­ing from phys­i­cal ad­ver­saries. This means we need a way to gen­er­ate such a se­cret when an ac­count is cre­ated, to up­date or mod­ify it, and to store it se­curely.

Other at­tacks

Spoof­ing ses­sion greeters: Way­land should im­pose re­stric­tions on the ca­pa­bil­i­ties of un­priv­i­leged ap­pli­ca­tions to leave some de­sign space for greeter de­sign­ers to make their UIs dis­tin­guish­able from nor­mal apps’ win­dows. For in­stance, un­priv­i­leged fullscreen win­dows shouldn’t be modal, and greeters could be let to dis­play au­then­ti­ca­tion di­a­log se­crets to users. Any in­ter­faces re­lated to know­ing whether the user is ac­tive or in­ac­tive or re­lated to (es­pe­cially au­to­matic) ses­sion lock­ing and greeter pref­er­ences are good can­di­dates for priv­i­leged op­er­a­tions as they would al­low an at­tacker to time the spawn­ing of a fake greeter and pre­vent the real one from be­ing in­voked.

En­vi­ron­men­tal at­tacks may also arise: if a dis­tri­b­u­tion al­lows user-in­stalled lo­cale files, a ma­li­cious app may re­place the de­scrip­tions of au­tho­ri­sa­tions in or­der to fool the user into be­liev­ing it is ask­ing for more be­nign priv­i­leges than it ac­tu­ally does. Like­wise, some theme en­gines may give theme de­sign­ers the op­por­tu­nity to cus­tomise spe­cific fields of a UI that may be used to de­sign a di­a­log hid­ing away se­cu­rity de­tails such as the app name and in­ject­ing tex­tual con­tent in­stead (some­thing eas­ily fea­si­ble with CSS 3 for in­stance).

Man­age­ment of in­ter­preters: When an ap­pli­ca­tion is ex­pected to run user-sup­plied un­trusted code, it should not qual­ify for priv­i­lege grant­ing (or only for dis­pos­able ones). This con­cerns in­ter­preters such as Python which can for in­stance cause the GNOME Keyring to not cor­rectly iden­tify the re­quest­ing app (mis­tak­ing it for the /usr/bin/python bi­nary). We might need some in­ter­preter-spe­cific black magic or hacks to iden­tify apps within Python and this is well out­side my do­main knowl­edge, so I’ll leave this is­sue aside for now and would wel­come any con­tri­bu­tion to our de­sign!

App iden­tity spoof­ing: In a very sim­i­lar fash­ion to the in­ter­preter prob­lem, Win­dows Vista shipped a bi­nary that al­lowed run­ning Con­trol Panel plu­g­ins with a Mi­crosoft-signed util­ity’s iden­tity (link here), hence pre­vent­ing users from know­ing which app re­quired au­tho­ri­sa­tions. In OS X, spoof­ing the app’s name, the de­scrip­tion of the de­sired per­mis­sion and a bunch of other things was also pos­si­ble at least in 2009, though I didn’t check how re­pro­ducible that is­sue is now. The great flex­i­bil­ity of their per­mis­sion re­quest­ing API surely made it very easy for mal­ware writ­ers to lie to users about their in­ten­tions and what it was they were ask­ing for (click here for more). Even bet­ter, some UIs don’t even at­tempt to show the app’s iden­tity and just leave the user clue­less.

Link­ing to or in­ject­ing code into priv­i­leged apps: What wor­ries me more is when a gen­uine app that is priv­i­leged by de­fault (e.g., your vir­tual key­board soft­ware) or can ac­quire priv­i­leges through the user (a Skype call in which you tem­porar­ily au­tho­rise screen shar­ing) is ex­ploited into run­ning ma­li­cious code. There are a num­ber of ob­vi­ous tech­niques for that such as LD_PRELOAD code in­jec­tions that would trig­ger some ma­li­cious code in gen­uine au­tho­rised ap­pli­ca­tions (ex­am­ples here and here), or hook­ing into a run­ning priv­i­leged pro­gram and in­ject­ing code us­ing ptrace. These at­tacks are very tough to de­fend against and will be ex­am­ined in a fu­ture ar­ti­cle (prob­a­bly fea­tur­ing PID name­spaces).

5. Se­cu­rity Re­quire­ments

The iden­ti­fied at­tacks al­ready give us an idea of what re­quire­ments must be used to de­sign ap­pro­pri­ate auth UIs:

1. Un­priv­i­leged ap­pli­ca­tions should not be let to read/mod­ify the in­put re­ceived by other ap­pli­ca­tions’ win­dows
2. Ap­pli­ca­tions hold­ing any kind of priv­i­leges must be pro­tected from all forms of code in­jec­tion / de­bug­ging.
3. Ap­pli­ca­tions should re­ceive priv­i­leges (and more so be priv­i­leged by de­fault) only if they can­not be in­voked / con­trolled by other un­priv­i­leged ones
4. In­ter­pre­tors of any kind should never re­ceive a priv­i­lege, un­less the piece of code be­ing in­ter­preted can be safely iden­ti­fied and the priv­i­lege can­not be reused/shared
5. Au­tho­ri­sa­tions make much more sense in a sys­tem where apps are sand­boxed and ac­cess to file sys­tems is lim­ited. If you can’t take a screen­shot but can call the screen­shot app and then read the screen­shot file, then screen­shot-tak­ing priv­i­leges are use­less
6. There should be a GUI de­bug­ging mode where de­vel­op­ers can record the auth UI, per­form au­to­matic test­ing, etc.
7. The UI should al­ways spawn through a trusted path, with an en­vi­ron­ment en­tirely con­trolled by the com­pos­i­tor; if the user can use a pre­vi­ous en­vi­ron­ment, it should be em­pha­sized that this is an at­tack vec­tor, and there should be no way for any third-party to en­able this op­tion prior to the UI be­ing called
8. Op­er­a­tions lead­ing to au­tho­ri­sa­tions should be doc­u­mented and lim­ited, con­vey a clear mean­ing; Do not al­low cus­tom au­tho­ri­sa­tions (else who would ver­ify the de­scrip­tion of the au­tho­ri­sa­tion is clear to the user?)
9. Apps must be iden­ti­fied clearly by the com­pos­i­tor (names taken from .desktop files in /usr, ab­solutely never from some­thing mod­i­fi­able by a user-run process)
10. Au­then­ti­ca­tion di­alogs should au­then­ti­cate them­selves in a way very ob­vi­ous and non-time-con­sum­ing for the user
11. In an ideal world, there would be one win­dow per process and the user would know which win­dow rather than which process is au­tho­rised to do some­thing (the ex­pla­na­tion be­hind this one is quite off-topic and will come in a later ar­ti­cle)
12. In an utopian world, the user knows which data can be af­fected by an au­tho­ri­sa­tion (e.g., whether their bank web­site cur­rently on screen will ap­pear on a screen­shot, which files’ con­tent can be leaked to an app, etc.) so s/he can make a `blink of an eye’ de­ci­sion; the ef­fects of au­tho­ri­sa­tions should be tan­gi­ble

6. Au­tho­ri­sa­tion UIs

Be­cause I’m not so con­vinced that we’ve yet found a UX that makes spoof­ing un­tractable by de­sign, I be­lieve it’s im­por­tant to sep­a­rate au­then­ti­ca­tion from au­tho­ri­sa­tion so that spoof­ing does not com­pro­mise valu­able to­kens (i.e., au­then­ti­ca­tion cre­den­tials). Au­then­ti­ca­tion has, for long, been used as a proxy for au­tho­ri­sa­tion on in­for­ma­tion sys­tems, as­sum­ing maybe that with the all-too-flex­i­ble APIs an app can use to im­per­son­ate the user who runs it, ask­ing a user for a se­cret was the only way to dis­tin­guish her from the app. Since we’re speak­ing about win­dow iso­la­tion in Way­land then we can fi­nally start to put some trust on GUI in­ter­ac­tions with the user con­vey­ing an au­then­tic rather than fab­ri­cated mean­ing. Hence, GUI op­er­a­tions may be­come a vi­able proxy for au­tho­ri­sa­tion to­kens. An au­tho­ri­sa­tion to­ken is typ­i­cally a one-time use ob­ject gen­er­ated by a trusted au­thor­ity (the com­pos­i­tor) and used by the sys­tem con­trol­ling ac­cess to priv­i­leged in­ter­faces (the WSM). Such to­kens can be dis­trib­uted by hav­ing the user in­ter­act with an au­tho­ri­sa­tion UI con­trolled by the com­pos­i­tor.

Ask­ing for priv­i­leges

Es­sen­tially, au­tho­ri­sa­tion UIs re­quire that a user re­ceives in­for­ma­tion about a re­quest (the iden­tity of the re­quester and what is be­ing asked for) and makes a de­ci­sion (a “Au­tho­rise” and a “Deny” but­ton, or vari­ants in for­mu­la­tion). Ad­di­tional in­for­ma­tion can be given such as the his­tory of au­tho­ri­sa­tions for the re­quester, the du­ra­tion of the au­tho­ri­sa­tion or whether the sys­tem has any trust in the ap­pli­ca­tion (if pos­si­ble). Any­thing pro­vided by the app it­self should be left out of the UI as at­tack­ers will make sure to ex­ploit it – typ­i­cally one should not let the app ex­plain why the au­tho­ri­sa­tion is be­ing re­quested, as users’ de­ci­sions are in­flu­enced by such in­for­ma­tion. Be­sides, it is a well known fact among HCI prac­ti­tion­ers that peo­ple get ha­bit­u­ated to com­puter prompts and tend to ig­nore their con­tents when they are fre­quent enough. Se­cu­rity prompts of­ten of­fer no ben­e­fit for the ful­fill­ment of users’ pri­mary task and so are just treated as an un­avoid­able dis­tur­bance. There of­ten is no no­tice­able im­me­di­ate con­se­quence to a wrong se­cu­rity de­ci­sion, and so users will be more likely to au­tho­rise sys­tem­at­i­cally than if they could mon­i­tor how the au­tho­ri­sa­tion is be­ing used. Hence, I do not as­sume that the user does re­alise:

• which app is ask­ing for a priv­i­lege
• what priv­i­lege is be­ing re­quested
• how long it will be granted for

I’m in­ter­ested in strength­en­ing the ba­sic au­tho­ri­sa­tion di­a­log so as to ob­tain stronger ev­i­dence that the above prop­er­ties hold. When it comes to the priv­i­lege be­ing prop­erly iden­ti­fied in a blink-of-an-eye, I can only think of hav­ing a very ef­fec­tive vi­sual rep­re­sen­ta­tion of each priv­i­lege, such as dis­play­ing a large icon (pos­si­bly an­i­mated if it helps to come up with a rep­re­sen­ta­tion, e.g., data flows) on the di­a­log. Im­ages are recog­nised bet­ter than words (though not al­ways re­called bet­ter es­pe­cially if hard to la­bel, which means we should pro­vide the la­bel with the im­age). Recog­ni­tion is su­pe­rior prob­a­bly be­cause they con­tain richer in­for­ma­tion than short se­quences of words. For the same rea­son, im­ages can be made highly dis­tin­guish­able from one an­other for each priv­i­lege and hence help users no­tice a new priv­i­lege and take the time to read its de­scrip­tion. Be­low are some quick and dirty ex­am­ples of such vi­su­al­i­sa­tions (show­ing as well my de­sign it­er­a­tions).

• 
• 
• 

Know­ing Who’s Ask­ing

As for app iden­ti­fi­ca­tion, I don’t think that dis­play­ing a short name or icon promi­nently is suf­fi­cient. This data can­not be trusted es­pe­cially for ap­pli­ca­tions not in­stalled through one’s dis­tri­b­u­tion repos­i­to­ries. The user should see which run­ning ap­pli­ca­tion is re­quest­ing a priv­i­lege rather than just be given a name. Apps with­out a win­dow, panel plu­gin or other GUI el­e­ment can hardly ful­fill this re­quire­ment, be­cause users have noth­ing to hold on to to iden­tify whether that app is run­ning or to shut it down.

Be­sides, app names and icons iden­tify an ap­pli­ca­tion rather than a run­ning in­stance of it – a spe­cific win­dow or other tan­gi­ble en­tity the user can in­ter­act with. Tan­gi­bil­ity plays an im­por­tant role in fa­cil­i­tat­ing users’ un­der­stand­ing of a tech­no­log­i­cal phe­nom­ena (ex­am­ples on net­work in­fra­struc­tures and on file shar­ing mech­a­nisms), hence it would be de­sir­able to pro­vide a re­la­tion­ship be­tween the UI and the app, that makes the user feel which ap­pli­ca­tion is re­ceiv­ing a priv­i­lege. There are such re­la­tion­ships of spa­cial na­ture:

• Au­tho­ri­sa­tion UI within the app’s win­dow (when a win­dow ex­ists) – zero-step cost
• drag and drop or copy and paste an au­tho­riza­tion to­ken (made tan­gi­ble) to the app’s GUI – one-step cost
• us­ing tech­niques like in “Your At­ten­tion Please” – zero to many-steps cost

In this model, apps would lose their priv­i­leges when their GUI is shut (re­gard­less of whether the un­der­ly­ing process still runs) and be re­stricted from ac­quir­ing new ones. Ap­pli­ca­tions with­out a GUI could ob­tain a spe­cial priv­i­lege (“Per­form­ing priv­i­leged op­er­a­tions in the back­ground/with­out telling you”) to by­pass this re­stric­tion. Be­low are some ex­am­ples of au­tho­ri­son icon mock­ups I made (with one very ob­vi­ous trade­mark vi­o­la­tion that can­not be used). Ideas and cri­tiques are wel­come, quite ob­vi­ously.

7. Au­then­ti­ca­tion UIs

Au­then­ti­ca­tion is much more sen­si­tive to spoof­ing than au­tho­ri­sa­tion, as pre­vi­ously ex­plained. Let us re­view three de­fence mech­a­nisms we came up with for this task: un­spoofa­ble UI, Win­dows’s se­cure at­ten­tion se­quence, and UI au­then­ti­ca­tion to the user.

Stuff Only the Com­pos­i­tor Can Do

Mar­tin pro­posed that an un­spoofa­ble UI uses abil­i­ties that only the com­pos­i­tor has. For in­stance, a com­pos­i­tor can mod­ify the po­si­tion, size and dis­play of all win­dows. When an au­tho­ri­sa­tion UI is launched, win­dows that were al­ready open could have a wob­bly an­i­ma­tion ap­plied to them (un­til the UI is closed). Some an­i­ma­tions are even par­tic­u­larly ef­fec­tive at caus­ing epilepsy at­tacks! :-) If an­i­ma­tions can­not be ap­plied on a sys­tem (legacy GPUs, a11y is­sues, etc.), sim­ple mod­i­fi­ca­tions such as an Ex­pose-like dis­play of win­dows could in­di­cate that the com­pos­i­tor runs the au­tho­ri­sa­tion UI’s code.

The most com­pelling is­sue with ma­nip­u­lat­ing only win­dows is that it re­quires win­dows to be open in the first place. Other ap­proaches could in­clude taskbars, systrays or even the desk­top wall­pa­per, know­ing that in each case the in­for­ma­tion to be used must be hid­den from all desk­top apps the user runs and that it must vary or be rou­tinely cus­tomised by users. The idea is to dis­play/trans­form el­e­ments of the desk­top that ex­ist re­gard­less of the app re­quest­ing an au­tho­ri­sa­tion, and to make sure that a nor­mal app can­not dis­play ex­actly the same thing. It also mat­ters that the trans­for­ma­tion be­ing ap­plied is very con­sis­tent, so the user can be ha­bit­u­ated to it and no­tice dif­fer­ences more eas­ily. In­deed, an at­tacker may try to ap­ply an­i­ma­tions with generic win­dows placed ran­domly, or a generic task bar, hop­ing that the user will not pay at­ten­tion to the in­for­ma­tion dis­played in the back­ground. This is es­pe­cially true if such a UI is de­ployed in a sys­tem where the DE’s con­fig files and the wall­pa­per can be read by any ap­pli­ca­tion. The at­tacker may also try to run a sim­ple di­a­log with no an­i­ma­tions/trans­for­ma­tions if those are not ob­vi­ous. In any case, se­cu­rity re­mains mostly the re­spon­si­bil­ity of the user.

As far as I’m con­cerned, I doubt users make the link be­tween the pres­ence of cer­tain vi­sual cues in the back­ground rather than oth­ers and the fact that a UI is not a fake but con­trolled by the com­pos­i­tor. They prob­a­bly just ex­pect a win­dow to de­clare who it is run by – sys­tem or apps (links to se­ri­ous sur­veys/stud­ies on the topic much ap­pre­ci­ated), and I would as­sume that as long as the spoof looks sim­i­lar enough to the real UI, at­tacks will work. Let’s not throw the baby with the bath wa­ter, though. Such ideas may make it a tiny bit harder to abuse the user, at rel­a­tively lit­tle de­vel­op­ment cost. Be­sides, this mea­sure costs noth­ing to the user in terms of manda­tory ex­tra steps to take in a de­ci­sion process. This means the us­age of this de­fence mech­a­nism is op­tional and de­pends on the user’s will­ing­ness to waste time, rather than im­posed on her/him.

Ap­ply­ing Win­dows’ Se­cure At­ten­tion Se­quence

In­put fil­ter­ing in Way­land al­lows us to catch and process spe­cific key­board key se­quences that are not ex­posed to ap­pli­ca­tions. Win­dows uses the in­fa­mous Ctrl+Alt+Suppr se­quence (be­cause it was vir­tu­ally un­used by ap­pli­ca­tions at the time Vista was be­ing de­vel­oped) prior to dis­play­ing an au­then­ti­ca­tion di­a­log to its users. In­deed, users are ex­pected to no­tice au­then­ti­ca­tion UI spoofs be­cause these would fail to re­act to them per­form­ing the Ctrl+Alt+Suppr se­quence. The name for this se­quence is Se­cure At­ten­tion Se­quence (SAS later on).

Tim­o­thee pro­posed to re­cy­cle this idea in a slightly dif­fer­ent way. In his model, rather than the auth UI ask­ing the user to per­form the SAS, it is the fact of typ­ing the SAS that would al­low the auth UI to spawn and al­low the cur­rently fo­cused ap­pli­ca­tion to re­quest a priv­i­lege to the user. Apps would then have to ask the user to type a SAS in what­ever way they pre­fer, which al­lows users to do noth­ing if they’re not will­ing to au­tho­rise the ap­pli­ca­tion. This would al­le­vi­ate some of the ex­as­per­a­tion Win­dows users had with Win­dows User Ac­count Con­trol, at the ex­pense of some clar­ity on when the user’s ex­pected to au­tho­rise/au­then­ti­cate.

There are many po­ten­tial at­tacks and rea­sons for con­fu­sion here. What should hap­pen when the user presses SAS but no ap­pli­ca­tion is re­quest­ing priv­i­lege? What if an app asks the user to press SAS, and at­tempts to spawn an au­then­ti­ca­tion di­a­log be­fore the user does so (lis­ten to Ctrl+Alt se­quences to im­prove your odds)? Would they key in their pass­word? Even weirder is the case where an app spawns a spoof di­a­log right af­ter a suc­cess­ful au­then­ti­ca­tion with the com­pos­i­tor’s UI: the user would prob­a­bly con­sider this a glitch/bug and re-type their pass­word.

An app could also ask the user to press a SAS by giv­ing it a very cred­i­ble jus­ti­fi­ca­tion, and then ask the sys­tem for an en­tirely dif­fer­ent priv­i­lege, hop­ing that the user would not dou­ble-check the jus­ti­fi­ca­tion given in the com­pos­i­tor-con­trolled UI. As I’ve said be­fore, users are quite sen­si­tive to jus­ti­fi­ca­tions and would prob­a­bly be less on their guards af­ter they typed in their SAS since they’ve es­sen­tially al­ready made the de­ci­sion to au­then­ti­cate.

Some apps could even try to get the user to au­then­ti­cate with­out even both­er­ing with ask­ing for a SAS to be typed. Af­ter all, ma­jor Web broswers al­ready use keyrings with cus­tom mas­ter pass­words, and there prob­a­bly are a bunch of other ap­pli­ca­tions ask­ing for users to type pass­words on a reg­u­lar ba­sis. I’m ac­tu­ally in­ter­ested in hear­ing from de­vel­op­ers of such ap­pli­ca­tions’ opin­ions on re­plac­ing their au­then­ti­ca­tion mech­a­nisms with a sys­tem-pro­vided per-app keyring that only re­quires (se­cure) au­tho­ri­sa­tion. The keyring could store a de­cryp­tion key for those like Google Chrome who want to syn­chro­nise pass­words with a third-party server, yet al­low­ing users to use au­then­ti­ca­tion-free keyrings and hence re­duce the ex­tent of harm­ful au­then­ti­ca­tion ha­bit­u­a­tion.

All in all the de­sign sounds in­ter­est­ing but is not with­out con­se­quences. The main is­sue for me is that plau­si­ble at­tacks re­sult in cre­den­tial theft, in a sys­tem that does come with a sys­tem­atic cost to the user. We should only con­sider SAS mech­a­nisms if we can­not find bet­ter for the same in­ter­ac­tion cost.

Au­then­ti­cat­ing to the User

Apart from the afore­men­tioned anti-spoof­ing mea­sures, we’ve iden­ti­fied one key re­quire­ment for se­cure au­then­ti­ca­tion UIs: they must au­then­ti­cate them­selves to the user. Ob­vi­ously such a di­a­log should be modal and pro­tected from any form of record­ing, in­clud­ing ap­pli­ca­tions with screen record­ing or shar­ing priv­i­leges. The idea that was orig­i­nally pro­posed by GaMa on Lin­uxFR was to dis­play a se­cret im­age cho­sen by the user at ac­count cre­ation time. The rea­son I like the idea of an im­age is that it is eas­ier to recog­nise than a word or piece of text. Though, one must also con­sider ac­ces­si­bil­ity is­sues as­so­ci­ated with vi­sual con­tent, and so it should be made pos­si­ble for a se­cret to also take the form of a passphrase. Time’s run­ning and so I won’t be mak­ing mock-ups now for those di­alogs.

A se­cret could be gen­er­ated at two dif­fer­ent mo­ments of an ac­count’s life: when the ac­count is cre­ated in a GUI en­vi­ron­ment (Live OS in­staller or ac­count cre­ation from an ex­ist­ing sys­tem); or when the user en­ters the ses­sion for the first time (a bit in­tru­sive though). The lat­ter is also nec­es­sary should the user’s se­cret be erased (which may hap­pen when a disk dies, for in­stance). Dis­tri­b­u­tions could ship a data­base of ~120 dif­fer­ent thumb­nails un­sim­i­lar to one an­other, and of course these should be dis­played in a com­pletely ran­dom or­der to guar­an­tee di­ver­sity be­tween ac­counts for those users who don’t bother to pick one and just click “Next” (hope­fully these will be able to iden­tify and recog­nise their se­cret im­age over time be­fore they get at­tacked). When there is ev­i­dence the user can­not view im­ages (run­ning the high-con­trast theme, hav­ing checked a box in the in­staller in­di­cat­ing a11y is­sues, run­ning a11y soft­ware, etc.), these could be re­placed by a data­base of au­thor ci­ta­tions, or could be ac­com­pa­nied by a de­scrip­tion to al­low switch­ing back and forth be­tween the nor­mal and a11y modes of the desk­top en­vi­ron­ment.

When it comes to stor­ing this se­cret, we could ei­ther har­ness manda­tory ac­cess con­trol en­force­ment sys­tems (SELinux, TO­MOYO Linux, etc.), or cre­ate pri­vate filesys­tems for each process. Mar­tin thinks it should be fea­si­ble with Linux filesys­tem name­spaces (as sup­ported by systemd pro­vid­ing pri­vate tmp di­rec­to­ries to ser­vices). I will be look­ing into op­tions for process iso­la­tion (in­clud­ing FS) in the next few months any­way.

From this I con­clude that the main is­sue with un­spoofa­ble au­then­ti­ca­tion UIs is ac­cept­ing the idea of adding a step to user en­roll­ment on Linux sys­tems, which is not an easy one. How­ever, in a world where we still force au­then­ti­ca­tion af­ter au­then­ti­ca­tion down the user’s throat, I be­lieve the threat of spoof­ing is too big to be left un­ad­dressed.

8. Con­clu­sion & Ac­knowl­edg­ments

First of all I would like to thank Mar­tin Peres for our lengthy dis­cus­sions of the threat model and so­lu­tions and for com­ing up with some of the ideas ex­posed here. Like­wise, Tim­othée Ravier has helped shape part of this ar­ti­cle, and pseu­do­ny­mous lin­uxfr con­trib­u­tor GaMa has hinted a very use­ful de­sign idea for au­then­ti­ca­tion UIs.

In this pa­per, I’ve dis­cussed com­mon at­tacks against auth UIs, sum­ma­rized the needs and se­cu­rity/us­abil­ity re­quire­ments for the tasks of au­tho­ri­sa­tion and au­then­ti­ca­tion, and pro­posed ini­tial in­ter­ac­tion de­signs that would bring what I view as an ac­cept­able com­pro­mise be­tween us­abil­ity, user ex­pe­ri­ence and se­cu­rity. I want to in­sist on the im­por­tance of keep­ing a clear se­man­tic sep­a­ra­tion be­tween au­tho­ri­sa­tion and au­then­ti­ca­tion, as both tasks have very dif­fer­ent se­cu­rity risks as­so­ci­ated and as the cost of au­tho­ri­sa­tion can be greatly re­duced by avoid­ing re­plac­ing it with the more in­ter­ac­tion-heavy task of au­then­ti­ca­tion.

Be­sides, cre­den­tials spoof­ing would be harder if all le­git­i­mate au­then­ti­ca­tions they are ex­posed to are per­formed through a unique in­ter­face – so that they grow used to see­ing ex­actly the same thing. So what­ever so­lu­tion we de­sign for Way­land priv­i­leges must be re-us­able by other FOSS pro­jects that need to per­form au­tho­ri­sa­tion or au­then­ti­ca­tion (e.g., pass­word stores). Rather than rein­vent­ing the wheel, I think one should look to ex­tend/adapt polkitd’s API (to dis­tin­guish be­tween au­tho­ri­sa­tion and au­then­ti­ca­tion) and then con­strain the APIs for polkitd au­tho­ri­sa­tion and au­then­ti­ca­tion agents to re­flect on our iden­ti­fied re­quire­ments.

Way­land com­pos­i­tors could then use polkitd and their own auth agents to ex­pose the Way­land-de­fined priv­i­leges and the oth­ers I dis­cuss in this ar­ti­cle, should they want to. I be­lieve the Way­land pro­ject is an ex­cel­lent place to first ac­knowl­edge the need for bet­ter pol­ished auth UIs and to pro­vide the nec­es­sary in­fra­struc­ture laid out above. I hope to have demon­strated that build­ing safe auth UIs goes far be­yond the ex­tent of just a desk­top en­vi­ron­ment or just the graphic stack. The corol­lary to this is that com­pos­i­tor de­vel­op­ers, dis­trib­u­tors and ul­ti­mately app de­vel­op­ers could/should be is­sued with rec­om­men­da­tions on what next steps, so that we ul­ti­mately build a more se­cure and con­sis­tent ex­pe­ri­ence for Linux desk­top en­vi­ron­ment users. Hope­fully oth­ers will agree with me and I will be able to take a FreeDesk­top spec out of this ar­ti­cle. If you too think fix­ing Linux’s se­cu­rity is worth the ef­fort, please com­ment be­low!

Are you a stu­dent?

If you’re knowl­edge­able about us­abil­ity eval­u­a­tion (or er­gonom­ics/in­ter­ac­tion de­sign/UX), I’m look­ing for some­one to eval­u­ate the var­i­ous de­signs above (with an aca­d­e­mic pub­li­ca­tion in mind). This can be made as a UCL MSc pro­ject su­per­vised by me and Prof. An­gela Sasse, and I’m keen to ex­plore avail­able op­tions for non-UCL stu­dents will­ing to col­lab­o­rate with us.