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 <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
> >
--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
|
