On 05.05.21 22:11, Arrigo Marchiori wrote:
Hello Peter, all,
On Wed, May 05, 2021 at 05:44:17PM +0000, Peter Kovacs wrote:
On 05.05.21 14:37, Arrigo Marchiori wrote:
Hello,
On Wed, May 05, 2021 at 07:08:11AM +0000, Peter Kovacs wrote:
The best approach I believe is to add a whitelist feature as for
macro
files.
Users can add then the links they wish to approve.
Do you mean file-based whitelists instead of target-based?
I will try to explain myself better: the current filter on AOO 4.1.10
is target-based, because it is the target of the link that triggers
the warning. Are you suggesting to add a whitelist based on files, for
example "allow any links in documents from this directory"?
If so, would you use the same whitelist as for macros, or would you
introduce another one?
I do not think that it makes sense to allow
https://my.payload.crime/AOO_diskscrambler.ods to be seen as save
target for
opening and macro execution at the same time.
Better is to have both separated. And the simple practicable
solution is to
just add an own list which allows targets to be listed.
I see. But please let us distinguish targets and sources.
Well, yea this is a nice abstraction I did not make. Good one.
The macros' whitelist contains _directories_ (I don't really like
calling them folders, I hope you don't mind) whose files are trusted,
with respect to macro execution.
sure. Names are sound and smoke ;) - sorry can not resist this german
IT idiom.
In your reply above you seem to discuss a whitelist of _link targets_?
Not documents, containing links that shall always be followed?
Yes, I thought on the target of the link. For me was this the
important trait.
However if I think in which document I grant the security level. Hmm,
I think this makes the whole concept a lot easier.
Plus we would then one list. So we extend an existing feature.
If we would want to have a vision, where we should develop to, this
would be
mine:
We have One list and 2 properties. 1 property for hyperlink
whitelisting,
the other one for (macro) execution. I like our 4 security stages.
The four security levels currently available for macros, if I
understand correctly, are based on a combination of:
- digital signatures of the macros (signed or not),
- trust of certain digital signatures (certificate trusted or not),
- position of the document (directory whitelisted or not).
This is... quite complex IMHO.
That why I have written it is maybe a vision. And maybe it is to much.
Did you refer exactly to this model?
yes kind of. I thought that a hyperlink has some sort of certiicate
and an macro can have some certification and that is kind of the same
thing...
Or
shall we rather adopt a simpler one for links, for example only
considering the directories whitelist?
Now that I think on your approach I think we should only look at the
directory that the document has been opened from. But still I would
still rather configure it per directory, then in a general and work
with exclusions.
However this is maybe not so smart to implement now, since our profile
is not robust enough. It will break eventually, and then all nice
settings are lost. And that is not something I would like to have.
And to understand better: does AOO allow to sign individual macros? Or
just the document containing them? I don't think that it allows to
sign individual links within a document.
No it would not sign individual links on the document.- But don't we
have document signing?
For links we could check if the document is signed.
So summing up:
# Instead of checking where the hyperlink is refering to, only check
where the document has been stored. (Treat hyperlinks as macros so to
say.)
# As an enhancement we could add a model that checks for the nearest
applicable path to the document, and applies that rule.
Example for a customized setup on a POSIX filesystem (security level
3 =
very high and 0 = low; first value is hyperlink, second value is macro
execution of this origin):
/tmp (3,3) => Everything in the temp folder does not open links or
execute
macros
~/ (2,2) => something that is within the home path, but not a folder
listed
below, may execute signed macros or open targets that have a trusted
certificate
~/Downloads (2,3) => Downloads may open Links with a trusted
certificate but
not allow to execute any macros
~/onlymystuff (0,0) => this is my documents and I allow everything
possible
here.
~/macro_examples (3,1) => delivered example I do not want them to
execute,
but they may be not linked by another document.
ftps://securecontent.org ( 2,2) => this links pointing to this
target are
opened, and the downloaded file may execute macros if they are
signed with a
trusted key.
