[Veritas-bu] .SeCuRiTy.n files in / on Solaris
2003-03-03 11:07:32
Subject: |
[Veritas-bu] .SeCuRiTy.n files in / on Solaris |
From: |
ssesar AT mitre DOT org (Steven L. Sesar) |
Date: |
Mon, 03 Mar 2003 11:07:32 -0500 |
4.5MP3, Patched Solaris 8
Johnson, Tony -Research wrote:
> Can you tell us what version of Netbackup you are running and the patches
> you've installed?
>
> Please ignore the confidentiality message at the bottom of this...
> -----Original Message-----
> From: Steven L. Sesar [mailto:ssesar AT mitre DOT org]
> Sent: Monday, March 03, 2003 9:54 AM
> To: Cord Beermann
> Cc: veritas-bu AT mailman.eng.auburn DOT edu; Geof Milstein
> Subject: Re: [Veritas-bu] .SeCuRiTy.n files in / on Solaris
>
>
> Cord Beermann wrote:
>
>>Hallo! Steven L. Sesar hat geschrieben:
>>
>>[snip]
>>
>>
>>
>>>I am pretty P.O'd about this, as I spent the last hour or so tracking
>>>this down. I was minutes away from turning my disks over to Infosec.
>>
>>
>>It's nice to know when you are not the only who tries to figure out
>>how that /&§&%§"%& cracker hacked into the Backupserver. BTDT.
>>including hyperventilating.
>>
>>
>>
>>>Can someone please tell me why the engineers at Veritas decided it was a
>>>great idea to write files that look suspiciously "warez-y" to /,
>>>nonetheless, and leave this little detail undocumented (at least, I
>>>can't find any reference to this)?
>>
>>
>>It is somewhere in the archive of this mailinglist.
>
>
> That's cool, but A) this list is not documentation and B) it's
> ridiculous that this $$$$$ product writes files like that, anyway.
>
>
>
>>
>>>In the event that any of you see this on your machines, what created
>>>them was a test restore of some NT files onto my master server. We were
>>>having a problem with a restore, so I decided to test the sanity of the
>>>image itself by restoring locally to my master server, which obviously
>>>worked.
>>
>>
>>the .SeCuRiTy-Files contain some additional information of the
>>access-rights.
>
>
> I dunno:
>
> [netbackup1]-/root# strings /.SeCuRiTy.94
>
> dxpP3P
> dxpP
> dxpP
> dxpPI
> dxpP3P
> dxpP
> dxpP
> dxpPI
> dxpP3P
> dxpP
> dxpP
> dxpPI
> dxpPj
> dxpP
> dxpP
> dxpP3P
> dxpP
> dxpP
> dxpPI
> [netbackup1]-/root#
>
>
>>
>>>IMHO, this is shoddy and careless SW engineering, made even worse by
>>>lack of documentation this behavior.
>>
>>
>>Yup. there are some more 'nice' features of this kind in it.
>>
>>Cord
>
>
>
--
===================================
Steven L. Sesar
Ops. Sys. Programmer/Analyst, Sr.
Application Operations R10A
The MITRE Corporation
202 Burlington Road - R101
Bedford, MA 01730
tel: (781) 271-7702
fax: (781) 271-2600
email: ssesar AT mitre DOT org
mobile: (617) 893-9635
===================================
|
|
|