[Mageia-dev] RM replacement

[Colin Guthrie]

'Twas brillig, and andre999 at 05/08/11 06:50 did gyre and gimble:
> Luis Daniel Lucio Quiroz a écrit :
>> Le Jeudi 04 Août 2011 18:39:35 andre999 a écrit :
>>> Luis Daniel Lucio Quiroz a écrit :
>>>> Helo,
>>>>
>>>> As my experience in security field, to make Mageia more available in
>>>> enterprise environments, and specially those that are security
>>>> paranoid, i'm planning to port SRM.  SRM is a package that does a
>>>> "secure" file deleting according some security standards (i dont
>>>> remember right now names, i guess it is something in NIST, but that
>>>> doesnt matter really).
>>>>
>>>> My question is, what should be the procedure that when you install srm,
>>>> then the normal rm command could be replaced?  i was thinking in
>>>> pushing an alias but what other alternatives do i have?
>>>>
>>>> please comment,
>>>>
>>>> LD
>>>
>>> At first glance that sounds like a reasonable approach EXCEPT -- a
>>> system-level alias would be over-ridden by a user alias.
>>> A user could innocently have an alias such as :
>>> alias rm="rm -i"
>>>
>>> rm is in /bin
>>> - /bin/rm could be replaced with a link to srm, but I don't know if that
>>> would be considered acceptable.
>>> rm would have to be restored if srm were uninstalled
>>>
>>> - wouldn't a link in /usr/bin/rm be executed first ?
>>> Of course that doesn't cover execution with root privileges.
>>> An alias in root wouldn't necessarily work, as an admin could
>>> inadvertantly
>>> replace it with another.  (By loading a new file with some changed
>>> alias,
>>> for example.)
>>> But probably less likely than some user doing the same on their profile.
>>>
>>> There could be other approaches as well ... :)
>>
>> You are right! :)
>>
>> Well another option could be this:
>>
>> a. we change coreutils to install /bin/rm as  /bin/rm.vanilla (or
>> other name,
>> that really doesnt matter),
>> b. i change srm to install itself in /bin instead of /usr/bin
>> c. we place alternatives in both packages to provide /bin/rm, giving
>> preference to srm if installed, otherwise it will use rm of coreutils
>>
>> LD
> 
> That would probably be the ideal approach.  But it might take a while to
> get the changes accepted in coreutils.
> 
> Maybe it could be all done from srm ?
> On srm install,
> a. rename /bin/rm to /bin/rm.vanilla (or rm.original or ?)
> b. create /bin/rm link to /bin/srm

Definitely not. It's against the commandments: Thou shalt not mess with
another packages' files.

> On srm uninstall, we ensure that
> a. rm /bin/rm link
> b. rename /bin/rm.vanilla to /bin/rm
> 
> Hopefully that could be done reliably, with an uninstall script.

No, this is very bad.

It's what the alternatives system was designed to do for you, but I
really don't think that something as fundamental as rm should be messed
with in this way as I mentioned in my own email.

srm is an add on userspace tool. To implement secure deletes properly,
you would want support at a lower level (i.e in the kernel/fs).

I think srm should just be a tool people use explicitly when they want to.

Col



-- 

Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]