Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 22 Aug 2013 15:16:23 +0200
From: John Spencer <maillist-owl@...fooze.de>
To: owl-dev@...ts.openwall.com
Subject: Re: some issues encountered in Owl-3_0-stable-20130408-i686.iso.gz

On 08/22/2013 12:43 PM, Solar Designer wrote:
> Hi,
>
> On Thu, Aug 22, 2013 at 12:09:27PM +0200, John Spencer wrote:
>> yesterday i did an owl test install in order to compare its filesystem
>> permissions with that of my own distribution i'm working on.
>> i encountered a couple of (mostly minor) issues, which i'm documenting
>> here... feel free to ignore.
>
> Thanks for reporting these!  I think this is mostly owl-users rather
> than owl-dev material, but I'll respond in here since the message is
> already on owl-dev.
>
> I think Owl-current would have been a (slightly) better choice for your
> test.

indeed. did i miss a hint that "current" should be picked somewhere on 
the download page ?

>
>> 1) when run in virtual box with default settings, the kernel will detect
>> a non-SMP system and lock up after some PCI diagnostic messages.
>> assigning more than one CPU to the VM fixes that.
>
> Ouch.  I think it's the first time this is reported.  Do you have a
> suggested fix?

not really. to find out maybe one needs to compare if centos/rh behaves 
the same way and if not analyse which kernel config causes this behaviour.

>
>> 2) the documentation says that for installation "setup" and "settle"
>> should be used.
>
> Not exactly.  It says (or tries to) that if you install remotely, you
> might find it more convenient to configure the live system with "setup"
> first and then proceed with the actual install from a remote workstation
> with "settle".  In other scenarios, you probably won't find this
> possibility useful and would proceed with "settle" right away.
>
> In practice, we found this approach useful when asking a third-party
> (such as a data center technician) to configure the live system for us
> (with "setup"), so that we can proceed with the actual install ourselves
> (using "settle").
>
> Maybe the documentation is not clear enough.

OK, maybe i should have paid more attention. when reading READMEs my 
brain switches to turbo-mode and skips all text that seems irrelevant...

>
>> however settle does not detect changes done using setup,
>> so you end up having to assign a root password twice.
>> i also changed my keyboard layout with setup, (and not in settle), so
>> after the install my keyboard layout was still USA, which came as a
>> surprise (detected when the ":" did not work, so i couldnt exit vi).
>
> Actually, both utilities detect the current system's networking
> settings (thus, "settle" will pick up the networking settings prepared
> with "setup"), but IIRC not anything else.  And you'll need to enter the
> networking settings sub-menu and "save" the settings.
>
> I'm not sure if we need to change that.

from my quick reading it appeared as if setup does basic configuration, 
which is then engraved to disk using settle.
maybe it could help if settle is mentioned first in the INSTALL file and 
setup mentioned later as the tool to switch current config.

>
>> 3) the passwd utility does not allow setting a weak password.
>> i understand that it somehow makes sense to enforce good security,
>> but OTOH on test installations that will never ever connect to a real
>> ethernet cable you really don't want a 20 letter password.
>> in my sysadmin past, more than 90% of linux installs were test
>> installations.
>> i ended up copy/pasting a weak password hash manually into
>> /etc/tcb/root/shadow...
>> imo there should be a way to make passwd do what the admin wants without
>> forcing him to edit the shadow file.
>
> As an alternative, you could have edited /etc/passwdqc.conf changing
> enforce=everyone to enforce=users.

indeed, this sounds like the right thing to do. if only i had known 
earlier ;)
perhaps this could be mentioned in the text shown by passwd ?

>
> Personally, I find it easy to come up with and type a password that
> passes the checks, even for test installs.  It does not have to be 20
> letters.  You may use e.g. 3 short words with a combined length of 11
> characters (including whitespace) or more.
>
>> 4) after the install, the Owl documentation is nowhere to be found.
>> apparently it's only on the CD-ROM media. imo it should be installed on
>> hdd and the /etc/motd as well.
>
> Yes, maybe.
>
>> 5) adduser user ; su user
>> bash: /root/.bashrc: Permission denied
>
> Isn't this normal?  You use "su - user" to more fully switch to the
> user's environment.

seems strange though that it tries to execute root's bashrc. it looks as 
if $HOME is not set correctly, which the su tool shipped on opensuse 
sets in any case, whether loginshell or not.
btw, sabotage distribution now uses 
https://github.com/rofl0r/hardcore-utils/blob/master/su.c which does the 
same.

>
>> 6) very old find utility
>> i used the following command to search for world writable files:
>> find / ! -type l -perm -002  2>/dev/null
>>
>> turned out that the ancient installed version does not even support the
>> ! type syntax, so it appeared as if Owl has no world-writable files at
>> all...
>> (btw, even current busybox find supports all options in that find statement)
>
> You probably did something wrong in that test.  What shell were you
> using?  Did it possibly interpret the "!" character itself?

i typed the command as above into the shell (bash).

>
> While our version of findutils is not very recent, it is also not that
> ancient.
>
>> 7) very old gcc
>
> Owl-current has newer gcc.
>
>> it's not even possible to build a kernel with a GCC that old.
>
> Depends on kernel version. ;-)  Anyway, to build recent kernels you need
> Owl-current.

yes, owl-current looks like what i wanted when i searched the ftp for 
the most recent version...

>
>> and indeed when looking at
>> http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/kernel/linux-2.6.18-348.3.1.el5.028stab106.2-owl.diff?rev=1.1.2.2;content-type=text%2Fplain
>> it appears as if a good part of the patch are compiler version
>> workarounds. while i personally like having a patch for old gcc versions
>> and a recent kernel, in this case it only adds unwanted noise to the
>> patch. but then, maybe there's a better place to look for the single
>> patches openwall applies to the kernel (lots of small topic patches) ?
>
> No, we don't maintain broken-out patches.  That -owl patch is not large,
> and is easier to apply as one patch when people do custom kernel builds.
>
> As you have noticed, we do still keep some workarounds for old gcc
> versions in the kernel -owl patch in Owl-current, but they only matter
> when building similar kernels on Owl 3-stable.  We'll drop them in
> Owl-current along with the move to RHEL6'ish kernels.

OK. the specific thing i am looking for is what causes all files in 
/proc to be non-world-writable.

http://serverfault.com/questions/243274/world-writable-file-analysis-linux-question 
suggests that it is not a security risk, however i suspect there must a 
reason owl disables it. in both cases it reduces noise when doing 
filesystem security assessment.

>
>> 8) lacking the documentation after the system was installed,
>> i tried to find out how to install an usable editor (gnu nano).
>> as it's a rpm based install, i tried to use yum, but it is not
>> existant. my suggestion is to create yum as a shell script
>> which justs prints the right information how to install stuff on owl.
>> $ yum install nano
>> this system uses XXX for package install, try XXX install nano instead.
>
> Frankly, there's no very good answer that we could have this script
> print right now.  We need to update things first, so that we could
> recommend the use of an up-to-date third-party repository (rather than
> something outdated like CentOS 4, which sort of works, but is not
> something we'd recommend now) or our own (future) repository.
>
>> 9) since nano is the default editor in debian and ubuntu, i think owl
>> should ship it in the default install as well.
>
> Yes, we should add nano, although personally I find VIM more convenient
> (and am annoyed with the Debian/Ubuntu default).

exactly the opposite here ;)

>
> Alexander
>

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ