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 <david-bronder AT uiowa DOT edu>
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 <
> Thomas.Denier AT jefferson DOT edu> 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:ADSM-L AT VM.MARIST DOT EDU] On
> >> Behalf
> Of
> >> Zoltan Forray
> >> Sent: Wednesday, February 25, 2015 12:12 PM
> >> To: ADSM-L AT VM.MARIST DOT EDU
> >> 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 <
> Thomas.Denier AT jefferson DOT edu> 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.
> david-bronder AT uiowa DOT edu
>
|
