[ubuntu-hardened] security center in ubuntu

Tue Apr 6 01:20:17 BST 2010

Nils-Christoph Fiedler wrote:
> I surely meant the usage of unskilled users with selinux. But my
> scepticism refers to the nsa history of selinux. I simply dont trust
> it out of this circumstance. We have a little private people
> monitoring through our government here in Germany, so its hard for me
> to trust a technology inspired or whatever by an instituion like that.
> Has anyone of you verified the code of selinux as not possibly evil?

I represent the loyal opposition to SELinux. I implemented an
alternative LSM in response to my personal distaste for SELinux.
I personally have taken an operating system through an NSA TCSEC B1
evaluation and two Common Criteria evaluations. On my hard earned
reputation I assure you that the SELinux kernel code is safe from
the presence of Evil.

I can not make any such assertions about the reference policy. The
kernel code has been subject to scrutiny by people who understand
the language it is written in and its stated intent. The same can
not be said of the policy, which is written in a special purpose
language and lacks a statement of intent. While I could walk you
through the kernel code and demonstrate that it is free from
sneaky tricks (even in the labeled networking code) I seriously
doubt that there is anyone could do the same for the reference
policy.

>
> In my eyes, besides hard techniques, human perception and a related
> lack of information is a great cause for the vulnerability of a
> system. Therefor the documentation of a "security-center" is very
> important. Today these important information that is needed for the
> user to see the necessity to take action is wide spread over the
> internet. (I dont know of a source, where much information about this
> issue is bundled.) And there will always be a statistical lack of
> security, when it is too uncomfortable for the user to take this
> action to protect him / her, because then it is easier to fall back to
> old samples of behaviour - thats human.
>
> For those packages, that are already part of the repositories /
> sources-list, there should be an easy way of installation via gui. The
> possibility to install the terminal or else doesnt meet the goal of
> ease, when you dont know, what to install.
>
> I guess thats it from over here for the moment. Please keep in mind,
> that I am using GNOME, so that I am not aware of maybe existing ubuntu
> specific guis concerning this issue in KDE.
>
>
> *Here's an open list, feel free to add / modify sth. missing:*
> + Email encryption like enigmail / seahorse
> + Firewall / iptables / port management (when I install gufw today,
> the default setting is OFF.. / sudo ufw status)
> + Antivirus like clamav (especially for machines standing in a local
> network with Windows maschines - I could never run clamtk for updates
> properly)
> + Usage of Bleachbit / Deborphan / wipe order (even cache and history
> data can be a vulnerability in case of local access to the maschine)
> + Easy installation of Truecrypt by integration into the sources-list
> by default
> + Testingscript for passwordstrength (the documentation should
> recommend [1] alternation, different level pwds and provide
> information about the syntax of good passwords, maybe with an
> implementation of John & rainbow tables / international dictionaries
> or an updatable local database, that stores the most known weak
> passwords, like "password", "god" and so on)
> + Combined Webbrowser user agent and language switcher (today only
> available as a plugin for Firefox as far as I know)
> + rkhunter / chkrootkit for rootkits, backdoor, exploits
> + Check whether a keylogger is running (e.g. lkl)
> + Permission check, using information provided by apt to identify
> changes to system files
> + moblock for ip-list blocking (maybe also for blocking known insecure
> tor endnodes)
> + tripwire for integrity
> + aide for file changes
> + logcheck
> + checksecurity
> + denyhosts
>
> *
> The documentation should provide information about:*
> + LVM encryption
> + [1], maybe with a little impressing mathmatical example of brute
> force and social engineering. Especially using the same password in a
> social network service and as the root password is kind of stupid.
> + Installation, usage and risks of tor, privoxy, ntp
> + The risk of using popular monopolists services
> + Maybe telling the users the risk of running sth as root via a
> selfclosing popup
>
>
> *Just some various links I found, related to this issue:*
> http://savannah.nongnu.org/projects/tiger
> http://savannah.nongnu.org/project/memberlist.php?group=tiger
> http://www.nongnu.org/tiger/
> http://brainstorm.ubuntu.com/idea/19648/
> http://brainstorm.ubuntu.com/idea/1282/
> https://help.ubuntu.com/community/MoBlock
> http://www.debuntu.org/intrusion-detection-with-aide
> http://packages.ubuntu.com/de/karmic/denyhosts
>
>
>
>
>
>
> ---
>
> Kees Cook schrieb:
>> On Fri, Apr 02, 2010 at 01:20:33PM -0000, Nils-Christoph Fiedler wrote:
>>   
>>> this idea, because today security is kind of a patchwork of different
>>> software, partly even not in the repositories of ubuntu, which makes it
>>>     
>>
>> I have to disagree about the "not in the repositories" bit, but I can
>> agree that a central UI for investigating security would be interesting.
>>
>>   
>>> accurate and a little annoying for more skilled ones, to install and
>>> setup those software separately. (talking about my personal experience)
>>>     
>>
>> The bulk of Ubuntu's security[1] is on by default and doesn't require
>> any user interaction.  For the other pieces, the way to configure them
>> is very different, since they do very different things.  To that end,
>> I think documentation is needed before a UI.  If we can't describe what
>> to do first, we have no hope of writing a UI to help do things.  :)
>>
>>   
>>> besides that i think there is a lack of "corporate design" or
>>> centralization of software and settings management in ubuntu, because
>>> you dont have one location where to individualize settings, but a
>>> handful of applications for that. (maybe this is also a problem of
>>> gnome)
>>> what do you think about that?
>>>     
>>
>> Sounds like a great project; I would be interested in what you come
>> up with.  Just itemizing specifically which subsystems to incorporate
>> would be a great first step, with consolidated documentation pointers
>> to follow, I'd imagine.
>>
>> Thanks!
>>
>> -Kees
>>
>> [1] https://wiki.ubuntu.com/Security/Features#Matrix
>>
>>   