SLC5 preparations and software security review

Tuesday 1 Jul 2008, 10:30 → 11:30 Europe/Zurich

513-1-021 (CERN)

- progress on slc5 preparations in CDB - plans for reviewing core software from the security point of view (lemon sensors and ncm components)

10:30 → 10:50 SLC5 progress

Pending issues from last meeting: - Swrep synchronisation - defaults creation done - status for srvta, pacct, sysacct, sysctl, - test machines: lxb6641 and lxdev3* to be retired. Asked for replacement machines (lxdev34-8) - review selinus-related error messages - lxplus,lxbatch (incl interactive packages, castor, LSF, ...) CDB new schema for components - arcd, consoleclient, snmp, iptables, settodesiredstate

Present: Jan Iven, Matthias Schroder, Ulrich Schwickerath, Ricardo Silva, Veronique Lefebure (chair and minutes), Jan van Eldik, Miro Siket

 

Excused: Tim Bell , Miguel Anjo

SLC5 preparation status

• Veronique:
  • swrep synchronisation in place
  • automatic creation of default templates in place
  • tests machines to be replaced by lxdev34-8. Will be announced
• Jan I
  • srvtab to be removed, work in progress
  • new version of iptable component: to be tested
  • selinux error messages reported on https://twiki.cern.ch/twiki/bin/view/ELFms/ScientificLinux5Port to be reviewed. People whose components are concerned should see with Jan how to get rid of the errors
• pending:
  • pacct,sysacct ?
  • Last bit with priority "1" is sysctl (Uli)
  • start working on lxplus/lxbatch:
    • Uli and Ricardo have no time before mid-of-July (bec of CC refurbishment hw requests)
    • Jan started to check for CASTOR to be build on SLC5
    • (Note: Veronique will be on holiday 8 to 24 August)
• Components to be updated to new schema:
  • arcd, consoleclient, snmp, iptables, settodesiredstate
  • See instructions on https://twiki.cern.ch/twiki/bin/view/ELFms/WriteNCMComponent#Conversion_of_old_components_to
• AOB:
  • Uli reports that there is no answer from Sharma who is supposed to release a new version of NOTD which does not build on SLC5. Veronique will try to contact him.
  • What is the status of the hardware templates for the new schema ? Noone here from TSI. To be followed up
  • Zuul is "OK' for SLC5, but people have to be aware that anything that would grep on /etc/passwd will break now.
  • Jan I: SLC released based on SL5.2
  • Jan I.: from the recent RH workshop: RH may decide to go away from XEn and move to KVM for ex. We should be carefull not to rely on the xen "xm" API: better use libvirt.

 

 

• all: parenthesis
  • discussion about how to have things tested. Please refer to minutes of ELFms meeting on that subject: http://indico.cern.ch/conferenceDisplay.py?confId=32017 :

Discussion and agreements:

• /test:
  • everyone is free to put anything under /test, and will benefit from the /test, and /preprod phases to test new software or new configuration. It means that, anyone is allowed to put under /test any template, but has to be aware that:
    • pro_software_packages_default_[arch]_[os].tpl are created automatically and should NEVER be edited by hand (else the change will be overwritten anyway)
    • anything under /test will end-up under /preprod and then under /prod according to the software upgrade schedule (SLA with users)
      
• /preprod:
  • NOBODY, except for the MUD (monthly upgrader on-duty), can put anything there.
  • the MUD will announce, one week in advance, on project-elfms@cern.ch, when /preprod will be frozen, so that you still have 1 week to put whatever you need under /test
  • for Service-specific templates ONLY: If you want to "test" something on "preprod" machines, or if you had no time to put your new templates under /test before that /preprod become frozen, then use a new stage, for example:
    • variable loadpath = list('usertest/vero/mypreprod','preprod','prod');
    • put under usertest/vero/mypreprod the templates you want to test
    • then move them yourself under /prod when you are ready.
      
    • this is allowed for service-specific templates ONLY, where you know exactly that only YOUR machines will be affected

 

---

 

 

 

10:50 → 11:10 Core software security

- lemon sensors to be run as "lemon" iso "root" else reviewed - ncm-components run under perl taint mode -t - scan components for possible holes - actuators ? /sbin/service ncm-cdispd start /sbin/service notd start /sbin/service nscdre start /sbin/service ntpd start /sbin/service olb restart /sbin/service rfiod start /sbin/service rootd start /sbin/service sendmail start /sbin/service snmpd start /sbin/service sshd start /sbin/service syslogd start /sbin/service syslog start /sbin/service tomcat5 start /sbin/service tsmclient restart /sbin/service xfs start /sbin/service xinetd start /sbin/service xrd restart /usr/local/lsf/etc/PoolFull.pl /usr/local/sbin/clean-tmp-partition-o75 /usr/sbin/spma_wrapper.sh CERN-CC packages on vocms01 [root@vocms01 ~]# rpm -qa | grep CERN-CC CERN-CC-glite-yaim-local-sw-dir-2.4-1 CERN-CC-logrotate-entries-1.0-0 CERN-CC-settodesiredstate-FS-3.0-14 CERN-CC-host-hwscan-1.5-11 CERN-CC-sysacct-1.2-13 CERN-CC-notd-1.22-1 CERN-CC-regis_client-1.3-2 CERN-CC-ncm-ncd-notd-1.2.11-1 CERN-CC-clean-partition-1.0-7 CERN-CC-ccm-conf-1.3.1-1 CERN-CC-LCG-fetch-cronentry-1.2-6 CERN-CC-motd-1.5-0 CERN-CC-sindes-0.1-2 CERN-CC-fsprobe-1.0-7 CERN-CC-smart-1.0-1 CERN-CC-lbclient-1.6-2 CERN-CC-DataServices-tools-1.15-1 CERN-CC-sms-set-state-3.3-1 CERN-CC-named-1.2-4 CERN-CC-pttools-1.0-2 CERN-CC-edac-1.0-1 CERN-CC-LCG-create-users_conf-1.5-2 CERN-CC-tmpwatch-1.3-2 CERN-CC-spma-notd-1.10.21-1 CERN-CC-memtester-1.0-2 CERN-CC-renumber-this-host-1.1-0 CERN-CC-raidman-1.1-0 CERN-CC-ipmi-1.0-11

Present: Jan Iven, Matthias Schroder, Ulrich Schwickerath, Ricardo Silva, Veronique Lefebure (chair and minutes), Jan van Eldik, Miro Siket

Excused: Tim Bell , Miguel Anjo

Jan gave an introduction to the subject: It has been decided that the ELFMS code running by default on all quattor-managed machines will be reviewed from the security point of view. This includes:

• lemon sensors and actuators
• ncm components
• any other "CERN CC" applications, daemons etc
  

The things to look at are:

1. run sensors unpriveledged
2. run components in taint mode and fix warnings. On SLC5 taint mode is enabled by default on ncm-ncd
3. scan components for possible obvious weakness. Jan I. has prepared a scanning script for that .
   

For 2. and 3. Veronique will contact individual maintainers during July.

DISCUSSION:

• Jan and Ulrich think that
  • the review should apply on all pieces of software, not only the ones falling in the categories above.
  • it would be good to force RPM signatures both on swrep upload and at the spma level.
    • what about GRID packages which are currently not signed ?
    • which signature should we use ? a service one "elfms" and "quattor" ?
    • what to do when someone leaves. Can we easily revoke the signature and create a new one ? what are the implications on already existing packages ? on the hosts ? on rpmverify ?  who decides which public keys are valid? who maintain them ? we should estimate how much this would cost
• Ulrich suggested that access to cdbserv should be done only via lxadm. (host.allow is currently empty on cdbserv)
• we need a policy for releasing new components. It should be centralised and reviewed before being put into production
• Lemon framework soon ready to have sensor run as root or lemon acconding to CDB configuration
  • sensor templates should be protected in CDB
  • actuators should use sudo. This should be configured both in CDB and at the RPM level
    • the sudo components scratches the sudoers conf file. Can that be improved ?
  • perl sensor to run in taint mode
  • more details is available on the LEMON web documentation