I would be OK with this - we don't even use dsmtca. All backups/restores happen as root or equivalent.
On Thu, Feb 26, 2015 at 06:45:46PM +1100, Steven Harris wrote: > Arrrgh! > > I have been working through a stack of changes to implement the last set of > updates for security issues on dsmtca. This is about 20 changes over 4 > months, and the workload imposed by this is considerable. I now find I > have to go back and do most of these again! (I could rant about the > futility of "best practise" change control but I will leave that for > another day in another forum). Lots of Domino 8.5 boxes that need a 32 bit > linux api are stuck on 6.2. > > Its fairly obvious that dsmtca is a bag of security worms, and that the > present whack-a-mole attitude to it is not working. So why not a rethink? > Every supported "server grade" TSM client OS has some version of Role Based > Access Control. This comes as standard in AIX since forever, and windows > since at least Win2K, don't know about the others. So its hardly bleeding > edge. > > A simple change to run under a "tsm" specific id with appropriate RBAC role > to do backups and restores would neatly sidestep all these rights elevation > issues. > > How hard can it be? > > Regards > > Steve > > On 26 February 2015 at 11:03, David Bronder <[email protected]> wrote: > > > There have been 3-4 security vulnerabilities recently for either Linux or > > all > > Unix and Linux clients, all related to the setuid "dsmtca" utility, with > > some > > overlap in versions (6.3-ish, IIRC) for some of the issues. > > > > For older/unsupported (or can't-yet-be-updated) clients, the workaround has > > been to restrict permissions on "dsmtca" (either remove the setuid bit > > entirely, or limit access to it to trusted users via group permissions or, > > I > > suppose, ACLs). The impact of the workaround is that non-root users > > without > > explicit (e.g. group-based) permissions for "dsmtca" won't be able to use > > the > > TSM client. > > > > We used this workaround for our 6.2 clients until the 6.2.5.4 release, > > which > > wasn't initially available. (The advisories previously said to contact > > support for the fix, which I did; they published 6.2.5.4 a couple weeks > > later. I suspect the devs were hoping they could get away with not > > building > > a 6.2 release with the fixes, since 6.2 drops from support in April... :-) > > ) > > > > =Dave > > > > > > On 02/25/2015 02:00 PM, Zoltan Forray wrote: > > > Where are you getting the bulletins/alerts from? I wouldn't have know > > > about it if it wasn't for your posting. I have passed this on to my > > folks > > > - we too have old clients going back to 5.3 and older (IRIX?) > > > > > > On Wed, Feb 25, 2015 at 12:55 PM, Thomas Denier < > > [email protected]> wrote: > > > > > >> The body of the bulletin I received states that the affected platforms > > are > > >> AIX, HP-UX, Linux, Solaris, and Mac. > > >> > > >> -----Original Message----- > > >> From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf > > Of > > >> Zoltan Forray > > >> Sent: Wednesday, February 25, 2015 12:12 PM > > >> To: [email protected] > > >> Subject: Re: [ADSM-L] Privilege escalation bug > > >> > > >> Does not specifically say if it includes SOLARIS (only says "*UNIX, > > Linux, > > >> and OS X allows local users to gain privileges via unspecified > > vectors.*"). > > >> Do I assume since it says "UNIX" SOLARIS is includes? We have some old > > >> Domino Solaris boxes (supposed to go away some time soon....) still > > running > > >> 6.1.3.... > > >> > > >> > > >> > > >> On Wed, Feb 25, 2015 at 10:56 AM, Thomas Denier < > > [email protected]> wrote: > > >> > > >>> I received a security bulletin from IBM yesterday regarding "Tivoli > > >>> Storage Manager Stack-based Buffer Overflow Elevation of Privilege: > > >>> CVE-2014-6184". The affected version/release combinations listed in > > >>> the bulletin run from 5.4 to 6.3. We still have one Linux system with > > >>> 5.3 client code. Can I treat the list of affected releases as an > > >>> explicit assurance that the 5.3 client does not have the vulnerability > > >>> discussed in the bulletin? The alternative possibility that worries me > > >>> is that 5.4 is the oldest level IBM thought it worthwhile to check. > > >>> > > > > -- > > Hello World. David Bronder - Systems > > Architect > > Segmentation Fault ITS-EI, Univ. of > > Iowa > > Core dumped, disk trashed, quota filled, soda warm. > > [email protected] > > -- -- Skylar Thompson ([email protected]) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
