Nemrég találtam rá a "Joint Strike Fighter Air Vehicle C++ Coding Standard"-ra. Két dologra voltam igazából kíváncsi. Egyrészt, hogy egy ilyen komoly valaminek a programozásakor milyen dolgokat írnak elő úgy általában, a másik, pedig, hogy a biztonságos programozási szempontok milyen formában jelennek meg benne.

Egy apró megjegyzés. Engem, aki soha nem dolgozott beágyazott rendszerek fejlesztésén újra és újra csodálkozással tölt el, hogy az üzleti rendszereken túl (ahol "látszik" a program), programok mozgatnak, irányítanak fizikai dolgokat is. Egyszer olvastam, hogy a lopakodó bombázó lopakodási képességei érdekében olyan kompromisszumokat kellett kötni, hogy a gép a levegőben körülbelül úgy viselkedik mint egy tégla. A többit programok pótolják ki. Szóval a C++ kód itt egy 100 millió dolláros eszköz vezérlésére kell.

A doksit elolvasva az látszik, hogy nem csak a kötelező köröket akarták megfutni. A kódolási szabvány túlmegy a szokásos szintaktikai dolgokon. Tipikus megoldásként a magyar piacon én eddig azzal találkoztam, ahol egyáltalán ilyennel foglalkoztak, hogy behivatkozzák, mondjuk a Java coding standardot és kész. Addig amig a JCS az 90% szintaxis és 10% practice, addig itt az arány fordított. 

Néhány terület, amivel foglalkozik:

• hibakezelés,
• engedélyezett könyvtárak,
• osztályok felépítése,
• memóriakezelés,
• dokumentálás, tesztelés.

Külön tanulságos a 4.2-es fejezet, ami a szabályok alkalmazási feltételeit tárgyalja. Itt bevezetik az RFC-kből ismerős should, will shall fogalmakat, de ami itt plusz, hogy megmondják milyen szintű felhatalmazás kell ahhoz, hogy egy shall (amúgy kötelező) szabálytól eltérjen a programozó: software engineering lead és sotfware product manager jóváhagyása, ami a CM szoftverben van dokumentálva. Tehát a kódolási szabvány "integrálva" van a fejlesztési folyamatba is. Ez pedig egy olyan ritka kivétel, ami nekem annyira szokott hiányozni.

Pl. 71.1-es szabály: "A class’s virtual functions shall not be invoked from its destructor or any of its constructors. "

A következő, amit észrevettem, hogy a szabvány az undefined, plattform függő, nehezen olvasható, félreérthető C++ programozási technikák használtát tiltja. Tehát ahelyett, hogy azt mondaná, tanuld meg az apró trükköket, inkább a biztonságos nyelvi részhalmaz használtát írja elő. Ezzel például erősen szembe megy a GOTW és a C++ könyvek általános tematikájától, ahol a különleges nyelvi leleményekre helyezik a hangsúlyt, sokszor a perverzióig fokozva a "na ez most szerinted mit csinál" játékot. Ez egyébként a programozás egyik alapkérdése: mennyire kell a nyelv határait feszegetni? Az egyik véglet, hogy nagyon, beleértve az adott plattform, fordító nüanszait is, a másik meg, hogy a nagyon átlagos, nagyon közepes programozóra kell a programot írni (mivel hosszú távon és statisztikailag ilyen programozók fogják a kódot karban tartani).

Végigolvasva a legtöbb dologgal egyet lehet érteni, még csak azt sem mondom, hogy a valóságtól elrugaszkodott formalizmusokat követelne meg. Az kifejezetten tetszett hogy a kód komplexitásával, az ovlashatósággal és a teszt lefedettséggel is foglalkozik. Azonban ez utóbbinál nekem hiányzott, hogy nem határozott meg célértéket, mondjuk 100%-ot.

De ami miatt végül is elolvastam a doksit az az , hogy kíváncsi voltam mennyire foglalkozik a biztonságos kódolási technikákkal. Nos, a meglepő dolog, hogy semennyire! Illetve majdnem.

Az biztos, hogy a divatos secure, security szavakra még hivatkozás sincs a dokumentumban. Már jobb a helyzet, ha mondjuk az overflow-t nézzük. Azonban "tudományos" is megvizsgáltam a kérdést. Fogtam a SANS top 25 software error leírást és megnéztem, hogy

1. A kódolási szabvány kitér e rájuk explicit.
2. A kódolási szabványt betartva mennyiben lehet az adott hibát elkerülni.

A téma specialitásából következik, hogy jó pár általános biztonsági hiba ebben a környezetben nem értelmezhető (pl. CSRF, de kár mert vicces lenne)

Íme az eredmény:

A fenti táblázat alapján adódik néhány tanulság:

• A SANS top 25 nem igazán húzható rá a JSF kódolási szabványra. Ennek az lehet az oka, hogy a SANS a leggyakoribb programozási hibákról szólnak és gondolom elsősorban üzleti szoftverekből van merítésük és főleg a most tipikus webes technológiákból. Ezért a speciális környezetekben előforduló hibákra nem igazán alkalmazhatóak.
• Ahol kapcsolatot lehetett találni a két dokumentum között (részben tárgyalja, vagy tárgyalja), ott is az látható, hogy a JSF a fejlesztői jógyakorlat oldaláról közelít és nem az esetleges hibák biztonsági aspektusai felől. Ez azonban nem meglepő, mert a biztonsági hiba a programkód szintjén amúgy meg hiba is. A hibákat a programozó "teszi" a kódba, ami ellen egy jó kódolási szabványban amennyire lehet készülni kell. Ezért is nehéz dolog a biztonságos programozási praktikák megállapítása, mert ha elrugaszkodunk a "strcpy függvényt nem szabad használni" szinttől, akkor utána már olyan kérdések maradnak, olyan területeket kell szabályozni, ami már a programozás napi gyakorlatába "gázol bele" (és így a programozó lelkivilágába).
• A JSF kódolási szabvány esetében a security nem önálló terület. A security, secure, authentication, trust szavak a dokumentumban elő sem fordulnak. Meg mondom őszintén nincs is ötletem, hogy miért nem. A dokumentum nem túl régi (2005), ezen azért csodálkoztam erősen. Vagy azt jelenti, hogy a JSF fejlesztésénél nagyon speciális trust környezetben működnek a programok, amiket elemezve arra jutottak, hogy nincs speciális támadási vektor amire készülni kell, vagy azt nem hozták nyilvánosságra, vagy ez kimaradt?!

Szumma-szummárum én úgy gondolom, hogy aki olyan cégnél van, ahol a méretnél fogva már fordítanak időt kódolási szabvány kidolgozására, használatára, érdemes belenézni ebbe a doksiba, mert legalább lát egy gyakorlatban használt, működő példát.

Tiborcz József