• Detect VMware guest in cfengine

    There are a few reliable ways to detect if the host is a VMWare guest.

    The ones below make the most sense.

    First choice:
    "vmware_guest" expression => returnszero("/bin/grep -qi vmware /proc/scsi/scsi","noshell");

    Second choice:
    "vmware_guest" expression => fileexists("/usr/sbin/vmware-toolbox-cmd");

  • Evaluation order of $PATH variable and why its important to understand.

    I recently came across a default SLES installation which has the following $PATH:

    (truncated for clarity)

    /sbin:/usr/sbin/:${HOME}/bin:/bin:/usr/sbin/:/usr/local/bin ..........

    This at first glance appears as a security problem , as a malevolant user can add $HOME/bin/ls and a user can execute a different ls or other arbitrary command that does something totally different.

    However, changing the path around to :

    /sbin:/usr/sbin/:/bin:/usr/sbin/:${HOME}/bin:/usr/local/bin ..........

    Does not really help the situation. The security problem that is exploited by the faulty path, is not fixed.

    The security experts at SuSE explain:

    If a user has write access to directories belonging to another user, then it does not matter what the PATH settings are, the target account is very likely to be compromisable for any local attacker. This is not what a unix-like system protects against. Especially the root account is (must
    be) considered trusted, as it has the privileges to add/remove users or set new passwords – not to mention accessing all files in the system.

    In this case, the PATH setting is actually a feature: The user can substitute programs contained in /usr/bin and other, non-system bin directories by placing a script/wrapper/other version of the program within his own bin dir.

    The execution of a program and the control of what executes (such as with a command executed by the shell) happen at the same security level within a Linux system. Therefore, the PATH setting cannot be considered a security risk.

    Entirely different is the following problem: If the PATH is set to /tmp or another, world writeable directory, then its place in the sequence of directories does matter, of course. Even if these directories, or “.” for that matter, are moved to the end of the PATH variable, a local attacker can still place a script with the name of an anticipated typo into the directory, thereby tricking the user or root into running it. This is why we have the option to include “.” into the PATH, but it is disabled by default.

  • Owncloud

    I installed owncloud today on my private unix webserver.

    Installation was fast & painless with Mysql backend, but sqlite somehow didn’t work.

    This program really is an awesome web application, as it allows you many things. It even intergrates my roundcube webmail client painlessly.


  • SSH / TAR to copy over files

    Using tar and ssh to efficiently copy files preserving permissions

    This trick will tar a directory from a computer, but the file that it would normally create, is standard out, so it is redirected back to the script on the computer you are working on. The computer you are working on extracts the information directly, so there is no location where (redundant) files are stored.

    ssh user@machine “tar czpf – /some//data” | tar xzpf – -C /new/directory

    You are now directly copying data from the “machine-where-data-is” to the machine you are working on, using the benefits of tar (preserving permissions, links, etc) but not being hindered by the difficulties of tar. (making these possibly large files and so on.)
    I used this trick to copy users directories from one machine to the other.

    An alternative command, reverse and not crossing filesystem boundries:
    tar cXpf – /some/important/data | ssh user@destination-machine “tar xpf – -C /some/directory/”

  • ASUS O!Play


    Just a quick note. I bought an Asus O!Play in the store because I needed a new media client/player as the one inside my TV is simply too limited.

    The O!play had everything I needed and it supposed to implement nfs shares from the unix/linux world. Its supposed to be based on linux.

    Well thats for sure now! The asus box is a simple asus-cooked busybox install with their own app as its only task next to a login shell. The app takes care of everything including a small webserver.

    In one word: Fantastic!

    telnet >oplay.ip.address , login>root … / # admin access…. Not recommended for new people in the unix world, but how’s that for a DRM-free device.!.!. I already modified the start-script slightly to auto-mount my NFS shares and make them appear under “local storage” 🙂

  • Updating Gentoo

    Today, I started the task of updating my home_network gentoo hosts since its been a while.

    What a mess I have run into, baselayout2+openrc has been marked stable, luckily I caught the newsitem not to reboot before fixing the /etc/init.d directory with etc-update or similar tools.

    Next up, I have tons of broken packages and revdep-rebuilt wont get me out of the mess at once. So, I have to manually track packages who’s dependency libs are broken (DirectFB I am looking into you!) , which thankfully is not all that difficult because of the q-toolkit (qdepends and qdepends -r). Still, i would like to use 1-command to update my whole host as advertised on www.gentoo.org.


  • Finally, the time has come… CFEngine

    The amount of work that has not been automated bores me to death.

    Imagine changing your own user password every month (!) on x-hundredth hosts manually for different reasons.

    Of course, you can script it with an expect script and ssh-keys, but its still not ideal. What if your account is locked on one of them or the password changed manually at one time for a reason. then the expect script fails and the host in question is not completed.

    First up, to determine policies and to add Gentoo’s portage so Cfengine recognises it in package management. Nothing too elaborate, just a simple setup that works.

    package_changes               => "individual";
    package_list_command          => "/usr/bin/python -c 'import os; os.system(\"/bin/ls -d /var/db/pkg/*/* | cut -c 13-\")'";
    package_list_name_regex       => ".*/([^\s]+)-\d.*";
    package_list_version_regex    => ".*/[^\s]+-(\d.*)";
    package_installed_regex       => ".*";                  # all reported are installed
    package_name_convention       => "$(name)";
    #package_list_update_command    => "/bin/echo --sync";           
    package_list_update_command    => "/usr/bin/eix-sync";           
    package_list_update_ifelapsed     => "14400";                 
    package_add_command        => "/usr/bin/emerge -q --quiet-build";
    #package_add_command         => "/bin/echo Installing";
    package_delete_command      => "/usr/bin/emerge --depclean";
    package_update_command      =>  "/usr/bin/emerge --update";
    package_verify_command      => "/usr/bin/emerge -s";
    package_noverify_regex      => ".*(Not Installed|Applications found : 0).*";

    This causes portage to synchronise every 10 days and we use eix to speedup certain things.

    Next up, we will save this file but not yet activate it. First I used the default update_script that came with cfengine as a failsafe mechanism. Editted to suit my needs, I don’t need a


    with access to localhost ;-). Although these are mark’s unix pages of course. still, as a humourous sidenote maybe. Nope, editted out this one. Next up, I changed the place where cfengine keeps its masterfiles, for security-through-obscurity reasons. Although not real security, if it throws off even 10% of scriptkiddies it means it was successful.

    When the client’s intranet is ready, I will move the cfengine off the public interface despite the fact the traffic never sees the full unprotected internet. Hackers can be even within one’s own ISP after all 🙂

    Finally, I will configure cfengine to run shell-scripts on every host when present in a directory on its master and move the shell-script to an archive-directory along with the output logfiles.

    My basic setup is now finished and onward to a more difficult setup.