>allowdocu...@domain.com => block => -doc
>that would inherit GeneralRule but remove .doc from it
(-extension) will be NOT available
>If we have a very simple policy
>~GeneralRule => block => exe\-bin|doc|.....and 50 other types
this will be NOT available
policy (block=>.... , good=> ....) will inherit and will be combined
(-i) in front of a policy to skip inheritance will work
~Templates can only contain extension sets (exe\-bin|doc|.....and 50 other
types) NOT policy sets
This is the only way to get clear rules and processing. Otherwise it would
be (for example) possible to define policy set loops.
Thomas
Von: K Post <nntp.p...@gmail.com>
An: ASSP development mailing list <assp-test@lists.sourceforge.net>
Datum: 28.08.2017 02:00
Betreff: Re: [Assp-test] More PDF Javascript catches
>From what you described about GOOD rules (which was helpful), I'd suggest
adding something like this to the GUI
BLOCK rules cause specific file types to be blocked (but does not block
the others)
GOOD rules block all file types except for those specified in the rule
I don't see anything in the GUI that is that clear. Nowhere does it say
that GOOD overtly rejects everything else, that understanding is critical
to writing rules correctly.
I understand boolean logic just fine, what I don't know is how you intend
to use this logic and overrides, yes there's that word again, when
inheritance is introduced. Once you introduce inheritance, which I
obviously think would be a wonderful thing, we need to insure that
inheritance rules are clear.
I'll try this again, hopefully doing a better job of explaining my
thoughts.
If we have a very simple policy
~GeneralRule => block => exe\-bin|doc|.....and 50 other types
That would block all detected executable content, .doc files, and the 50
other types in the very long string.
*=> GeneralRule
would make this rule be enforced for all users
Now if we have a user allowdocu...@domain.com who we want to be able to
receive .doc files but still have everything else in GeneralRule blocked,
the question is how you want to make this happen?
We wouldn't want to use a GOOD rule for .doc, because then nothing else
would be allowed through (I understand that now, thank you).
So how do you plan to code it to allow us to remove .doc from the very
long GeneralRule definition for this one user?
Sure we could create a second policy like GeneralRuleButAllowDoc
definition that doesn't include doc, but then we're back to maintaining
that long definition in multiple places.
I'm hoping for some sort of setup where we could use a minus (-) syntax
with inheritance to remove or overide types from existing definitions:
allowdocu...@domain.com => block => -doc
that would inherit GeneralRule but remove .doc from it
We could also do
(-i)allowdocu...@domain.com => block => GeneralRule|-doc
which ignores inheritance, but has the GeneralRule referenced for the same
effect as the above rule.
See what I mean? I can't say how hard that would be for you to code, but
it would be a dream for us admins. Have a long general rule but for some
case need to remove ONE of those file types? Just use minus syntax and
it's like it never existed!
On Tue, Aug 22, 2017 at 1:57 AM, Thomas Eckardt <
thomas.ecka...@thockar.com> wrote:
>Yes, but it's unclear if good means that's all that is allowed or if it's
an override of block.
Did you read anywhere in this section the word 'overwrite'?
Is it too hard to think a boolean OR? - or reverse, a boolean AND?
block if
the mail and flow direction matches a defined block rule
OR
the mail and flow direction NOT matches a defined good rule
the same is
pass if
the mail and flow direction NOT matches a defined block rule
AND
the mail and flow direction matches a defined good rule
>And then what happens with inheritance if an inherited policy has a block
only, line that inherits that has a good, etc.
What a question ?? It happens the resulting rule, what else!?
Von: K Post <nntp.p...@gmail.com>
An: ASSP development mailing list <assp-test@lists.sourceforge.net>
Datum: 21.08.2017 19:25
Betreff: Re: [Assp-test] More PDF Javascript catches
On Mon, Aug 21, 2017 at 12:56 PM, Thomas Eckardt <
thomas.ecka...@thockar.com> wrote:
>I'm wondering if you should pose your question as a new thread so that
others who typically ignore threads that they're not originally a part of
could chime in.
This is the development test list - I expect, that every thread is read by
everyone.
But you know they don't. Your call, just a suggestion.
>I definitely don't understand the good and blocked syntax of the current
address can be sender and/or recipient (both local and/or foreign)
block = block-in + block-out
block-in - for incoming mails
block-out for outgoing mails
same for good
rule:
block if
the mail and flow direction matches a defined block rule
or
the mail and flow direction NOT matches a defined good rule
just simple - isn't it?
from the GUI
..At least one of the above option must be defined in a line - a maximum
of all (six) could be defined, if this makes sense.....
This should and it is confusing (means read again) .... 'all six' makes
never sense!!!!
Yes, but it's unclear if good means that's all that is allowed or if it's
an override of block.
And then what happens with inheritance if an inherited policy has a block
only, line that inherits that has a good, etc.
And that's why I suggested the - negation syntax, to clear this up. it's
simple for you, but despite reading the gui many times over and over on
this section it's not crystal clear as to what happens now. So, as long
as you're reworking this section, I'm suggesting the simplication.
>URL blocking
I'm sorry, this was an absolutely terrible choice of file extension on my
part. We're blocking the .url extension. Same questions below but this
time with the .doc extension for clarity:
Good / Block and inheritance
~policyname => block => exe\-bin|doc|bla
I definitely don't understand the good and blocked syntax of the current
UserAttach implementation. I think that could use some clarification in
the gui. If you're reworking the UserAttach concept, maybe we could
change this?
If policy1 is defined as above, and we want to remove URL blocking for a
user, how would we do that?
* => policy1
allowwordfileu...@domain.com => good => doc
Would that add of doc to good, thereby negating the block inherited from
policy1?
Does adding good to the user make it so that doc is the ONLY type that
person can receive?
* => policy1
(-i)allowwordfileu...@domain.com => block => policy1|-doc
in this above example, that user has inheritance turned off, gets policy1
and -doc removed from that list
or
* => policy1
allowwordfileu...@domain.com => block => -doc
Inheritance is on above, and doc is removed from that inherited list (I
think I like this syntax the best)
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally
privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no
known virus in this email!
*******************************************************
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
DISCLAIMER:
*******************************************************
This email and any files transmitted with it may be confidential, legally
privileged and protected in law and are intended solely for the use of the
individual to whom it is addressed.
This email was multiple times scanned for viruses. There should be no
known virus in this email!
*******************************************************
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
