AW: Re: Security risk of server side text editing in general and vim.tiny specifically

[Fiedler Roman <Roman.Fiedler () ait ac at>]

Hello Jan,

> From: Ian Zimmerman [mailto:itz () very loosely org]
>
> On 2017-11-03 11:07, Fiedler Roman wrote:
>
> > Due to the recent discussion on vim swap file use, I expected also
> > attraction of of evil-minded to the topic of text editing security and
> > thus an increase in attack probability on server side text editing in
> > general. Therefore I wanted to review our software qualification
> > criteria for text editing on servers, where vim/vim.tiny is used and
> > probably update the SOPs and guidelines.
>
> How much of this (and the parallel thread of course) applies to nvi?

Sorry about the parallel threads, Outlook removes the relevant mail headers 
without asking under some circumstances.

Nvi avoids the chmod/chown trickery, at least for Ubuntu Xenial. So all those 
bugs do not apply.

As written in another post, using /var/tmp in that way is really a bad idea. 
In my opinion it is a pity, that the vim recover redesign did not cleanly 
separate locking and recovery. In my opinion, a good solution would be to 
create a [].lock file where the file resides, thus also working across network 
shares, ... Recovery files should go only to user directories, where tmp dir 
cleanup is not an issue. When same user attempts recovery, his personal 
recovery copy is found anyway. If another user finds the lock, he has to 
decide his actions anyway, e.g. a) make the change without knowing the "lost" 
changes from another user, because it is urgent or b) find out, who the other 
use is, search his change files (if root and allowed), ....

With a lock file, nothing can leak. If "recovery of other user's changes" is a 
common procedure in some companies, a special setting could cause the lock 
file not to be empty but to contain the last editing user name, login time so 
that it is easier to contact that user.

LG Roman

Attachment: smime.p7s
Description: