- Alexander Leidinger - http://www.leidinger.net/blog -

Rants about JASS (Solaris Secu­rity Toolkit)

Recently I switched to a new client where the Solaris [1] Secu­rity [2] Toolkit (JASS) is exten­sively used. I am now in the process of updat­ing some things, among them are JET and JASS. As part of this work I reeval­u­ate the local JASS mod­i­fi­ca­tions. Pre­vi­ously a cus­tom JASS pack­age was used, but in case JASS is updated by Ora­cle [3] at some point in time (and an update is really needed, see below), this would need some amount of work to find out the dif­fer­ences and to for­ward port them to the new ver­sion. If every­thing is well doc­u­mented, this should not be hard to do, but the per­son doing the work also needs to find the up-to-date docs.

To make it more easy I decided to change this. I now install the offi­cial JASS pack­age via JET together with the lat­est patch for it, and then let JET copy our mod­i­fi­ca­tions over the installed pack­age. Instead of mod­i­fy­ing exist­ing dri­vers, I cre­ated our own dri­vers with a ref­er­ence to the dri­ver which served as a base.

While doing this I encoun­tered sev­eral short­com­ings of JASS on Solaris [4] 10.

There are sev­eral FS based checks which do not make sense to do for the FS of zones in a global zone (at least not the way I use JASS, so maybe a con­fig­urable way of chang­ing the behav­ior should serve for every­one). If zones are installed in /zones, you do not need to check for files with­out valid UIDs (you surely find a lot of files, as the users are defined inside the zones and not in the global zone) or sim­i­lar things (even not for world writable files, as the zones are installed in a root-access-only sub­tree and inside the zones there may be other secu­rity con­straints con­fig­ured inside JASS, read: it is the respon­si­bil­ity of JASS inside the zone to do this). An easy solu­tion would be to exclude those FS which con­tain zones (and as we only have one sub­tree, I just hard­coded this in sev­eral scripts [5]).

I also miss the pos­si­bil­ity (maybe I over­looked a sim­ple way) for the ssh check to limit the Allow­Root­Lo­gin to spe­cific hosts. JASS only checks yes or no, but can not limit it to spe­cific hosts (e.g. via “Match [6] IP/hostname”). Often you do not need to per­mit root-logins (RBAC/sudo/…), but some­times it is the only way to han­dle a par­tic­u­lar edge-case (or to speed up an action dra­mat­i­cally), and in such cases you do not want to allow root-logins more than necessary.

[12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56]Share/Save [57]
2 Comments (Open | Close)

2 Comments To "Rants about JASS (Solaris Secu­rity Toolkit)"

#1 Comment By Jason Call­away On August 11, 2011 @ 14:50


You bring up some good points. If you have made any cus­tomiza­tions to the JASS code base, feel free to send them over, and I’ll see if we can inte­grate them into the next ver­sion. FYI, SUN­W­jass 4.2.2 is avail­able here ( [58]). If you get a chance to test it, please let me know how it goes.


#2 Comment By netchild On August 11, 2011 @ 16:34

I will send you some­thing I can share later (maybe tomor­row). For things I can not share, I will give a description.