brute force ssh attack

[William Hooper]

Matthew Miller wrote:
[snip]
>>> We need to *address* that, not just
>>> say "this is approximately zero threat". Obviously education is part
>>> of it. A more sophisticated SE Linux could be another.
>> A more sophisticated SELinux would require a more sophisticated user to
>>  administer it.  Catch-22.
>
> Well, *that's* the place where it needs to be more sophisticated. The
> current SE Linux is basically like assembly-language. It needs to be made
> more understandable at a higher-level view -- and then more transparent.

Somewhere along the line, though, that user must have the ability to
change SELinux permissions, and/or have the permissions to change binary
files (for example package updates).

SELinux doesn't provide a way to stop and administrator determined to do
something unwise.  To use your example above (that I snipped), there is no
possible way to stop someone from following steps given in a pop up that
disable SELinux and install a program.  Or give a program the SELinux
permissions it needs to do whatever it wants to.

It still boils down to an education issue.  Don't allow random things to
install on your system.  Don't look at SELinux and file permissions as
things to be worked around because they get in your way.

Take the example a virus that spreads by using a password-protected zip
file, making the user: manually save the file, unzip it (using the
password), manually run the executable.  Nothing short of education can
stop something like that.

--
William Hooper