lorenzog's questions

I have a hypervisor running libvirt on a Ubuntu 18.04 system. I need to configure access so that user 'joe' can only manage one domain.

Recently, policykit moved from the .pksa configuration files onto .rules. However, Ubuntu 18.04 ships with an old version of Policykit:

# pkaction --version
pkaction version 0.105

All the relevant examples only include .rules files; the documentation also states:

If using versions of polkit prior to 0.106 then it is only possible to validate (user, permission) pairs via the .pkla files. Fully validation of the (user, permission, object) triple requires the new JavaScript .rules support that was introduced in version 0.106. The latter is what will be described here.

When I look at the only .pksa example, I see things like:

[Allow fred libvirt management permissions]
Identity=unix-user:fred
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Which is too generic. Am I correct in deducting that in Ubuntu 18.04, it is not possible to limit users to access a single domain via Policykit?

If that's the case, is there an alternative?

Note: a similar, unanswered question is: https://unix.stackexchange.com/questions/367731/libvirt-debian-restrict-user-domain-access

I need to bind to an OpenLDAP server to authenticate users, but I don't want this low-privileged or "delegated administrator" to be able to see more attributes than strictly necessary.

How do I reduce the attributes a bind user can see using a whitelist? What attributes are strictly necessary to authenticate users?

For example, there's no need for this specific bind user to see NTPassword and I suppose other attributes like home directory, etc.

This is what I did so far:

1. I have disabled anonymous bind:

   # disable anon bind
   dn: cn=config
   changetype: modify
   add: olcDisallows
   olcDisallows: bind_anon
   
   dn: cn=config
   changetype: modify
   add: olcRequires
   olcRequires: authc
   
   dn: olcDatabase={-1}frontend,cn=config
   changetype: modify
   add: olcRequires
   olcRequires: authc
   

2. I've created an "Applications" OU and a "gitlab" user:

   # file: applications.ldif
   dn: ou=Applications,dc=example,dc=com
   objectclass: top 
   objectClass: organizationalunit
   ou: Applications
   
   dn: cn=gitlab,ou=Applications,dc=example,dc=com
   cn: gitlab
   objectClass: simpleSecurityObject
   objectClass: organizationalRole
   userPassword: {CRYPT}.....
   

3. To create the user, I've used the LDAP admin user:

   ldapadd -xvvv -f applications.ldif -D 'cn=admin,dc=example,dc=com' -W
   

4. To restrict the 'gitlab' privileges, I've tried this:

   # file: give-applications-access.ldif
   dn: cn=config
   changetype: modify
   # allow Applications (e.g. GitLab) access to userPassword
   access to dn.chidren="ou=People,dc=example,dc=com" attrs=userPassword
     by dn.exact="ou=Applications,dc=eaxmple,dc=com" read
   

5. Then I've used ldapmodify to apply the previous LDIF:

   ldapmodify -xvvv  -D 'cn=admin,dc=example,dc=com' -W -f give-applications-access.ldif
   

Now I can successfully authenticate users in ou=People from gitlab. However, if I use e.g. jxplorer or ldapsearch with the gitlab user credentials, I can see all the user attributes except userPassword:

ldapsearch -h ldaps://ldap.example.com -p 636 -LLL -D 'cn=gitlab,ou=Applications,dc=example,dc=com' -s base -b "ou=People,dc=example,dc=com"  -s sub -W "(objectclass=*)" | grep -i userpassword | wc -l
0

What's going on here? I suppose gitlab is using sambaNTPassword to authenticate.. but I thought attrs=userPassword was read only, and now it's not even in the attributes.

Apologies for pasting all the commands - I'm leaving them here in the hope that others will find this useful. Most of the documentation I've found describes every single option available but doesn't give any good examples that are usable on recent versions of OpenLDAP; and most of the examples available concern editing slapd.conf and not the "new" database (cn=config) type, so it's hard to understand what's relevant.

UPDATE - the current ACL is:

olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read

I've followed this answer to read the ACLs which in my case were on {0}mdb: ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config 'olcDatabase={1}mdb'

I tried to set up my nagios install to check the availability of a SMTP service outside its backup hours. Unfortunately, it seems to be ignoring this configuration:

# a timeperiod to check only outside of zimbra's backup hour
# (combining the first with the second timeperiod)
define timeperiod {
    timeperiod_name     zimbra-backups
    alias               When zimbra is being backed up
    sunday              04:00-05:00
    monday              04:00-05:00
    tuesday             04:00-05:00
    wednesday           04:00-05:00
    thursday            04:00-05:00
    friday              04:00-05:00
    saturday            04:00-05:00
}
define timeperiod {
    timeperiod_name     always-except-zimbra-backups
    alias               24x7 except backup time
        sunday          00:00-24:00
        monday          00:00-24:00
        tuesday         00:00-24:00
        wednesday       00:00-24:00
        thursday        00:00-24:00
        friday          00:00-24:00
        saturday        00:00-24:00
    exclude             zimbra-backups
}

Which, then, is used with a new host:

define host {
    host_name               mailserver-except-backups
    alias                   mail server (outside backup hours)
    address                 yaddayadda
    notification_options        d,u,r,f
    use                     my-default-host
    check_period            always-except-zimbra-backups
    }
define service {
    host_name                   mailserver-except-backups
    service_description         SMTP service
    check_command               check_smtp!-t 30
    use                         my-default-service
    check_interval              2
    retry_interval              1
    }

I can't see what's wrong.. any clue? Here is one of the notification e-mail

***** Nagios *****

Notification Type: PROBLEM

Service: SMTP service
Host: mail server (outside backup hours)
Address: yaddayadda
State: CRITICAL

Date/Time: Sat Apr 27 04:03:16 CEST 2013

Additional Info:

Connection refused

Nagios is Core 3.3.1 running on a OpenBSD 5.2.

All of a sudden (read: without changing any parameters) my netbsd virtualmachine started acting oddly. The symptoms concern ssh tunneling.

From my laptop I launch:

$ ssh -L 7000:localhost:7000 user@host -N -v

Then, in another shell:

$ irssi -c localhost -p 7000

The ssh debug says:

debug1: Connection to port 7000 forwarding to localhost port 7000 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip: listening port 7000 for localhost port 7000, connect from 127.0.0.1 port 53954, nchannels 3

I tried also with localhost:80 to connect to the (remote) web server, with identical results.

The remote host runs NetBSD:

bash-4.2# uname -a
NetBSD host 5.1_STABLE NetBSD 5.1_STABLE (XEN3PAE_DOMU) #6: Fri Nov  4 16:56:31 MET 2011  root@youll-thank-me-later:/m/obj/m/src/sys/arch/i386/compile/XEN3PAE_DOMU i386

I am a bit lost. I tried running tcpdump on the remote host, and I spotted these 'bad chksum':

09:25:55.823849 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 67, bad cksum 0 (->3cb3)!) 127.0.0.1.54381 > 127.0.0.1.7000: P, cksum 0xfe37 (incorrect (-> 0xa801), 1622402406:1622402421(15) ack 1635127887 win 4096 <nop,nop,timestamp 5002727 5002603>

I tried restarting the ssh daemon to no avail. I haven't rebooted yet - perhaps somebody here can suggest other diagnostics. I think it might either be the virtual network card driver, or somebody rooted our ssh.

Ideas..?

In my current nagios installation I check for the existence of a remote backup through NRPE. In particular, my remote nrpe.cfg (on a Ubuntu 8.x) is:

command[check_zimbra_backup]=/usr/lib/nagios/plugins/check_file_age -f \\
/backupdir/zimbra_backup-$(date +%a).tar.gz -w 518400 -c 86400 

Running the command locally returned OK:

$ sudo su -m nagios -c "/usr/lib/nagios/plugins/check_file_age -f \\
/backupdir/zimbra_backup-$(date +%a).tar.gz -w 518400 -c 86400 "
FILE_AGE OK: /backupdir/zimbra_backup-Sun.tar.gz is 47661 seconds old and 10863637475 bytes

However, my logs showed CRITICAL:

nagios: SERVICE NOTIFICATION: zimbra backups;CRITICAL;notify-service-by-email;
FILE_AGE CRITICAL: /backupdir/zimbra_backup-Sun.tar.gz is 22373 seconds old and 10863637475 bytes 

Notice how it returns a critical state depsite the fact that the number of seconds reported (22373) is smaller than the warning parameters (86400s, or 24 hours).

The interesting bit is that running the NRPE plugin remotely returns something strange:

$ sudo su -m _nagios -c "/usr/local/libexec/nagios/check_nrpe -H HOST \\ 
-c check_zimbra_backup"
FILE_AGE CRITICAL: /backupdir/zimbra_backup-Sun.tar.gz is 23611 seconds old and 10863637475 bytes
ҷ?Oڷ`xڷ

Notice the last line, which looks like some sort of garbled output.

The check_file_age plugin is version v1750 (nagios-plugins 1.4.11)

I am trying to monitor my legacy zimbra installation (running on an outdated Ubuntu 8.x) from my nagios install (running on a more recent OpenBSD).

The problem is that when I run check_nrpe from the nagios server it complains:

nagios-server$ sudo su -m _nagios -c "/usr/local/libexec/nagios/check_nrpe -H ZIMBRA_HOST -c check_zimbra"
CHECK_NRPE: No output returned from daemon.

Note that the zimbra server's NRPE configuration runs:

command[check_zimbra]=/usr/lib/nagios/plugins/check_zimbra.pl

On the other hand, running the plugin locally on the zimbra server works fine from root:

zimbra-server# ./check_zimbra.pl 
HOST : ZIMBRA_HOST, ldap : OK, logger : STOPPED and zmlogswatchctl down, mailbox : OK, mta : STOPPED and zmmtaconfigctl down and zmsaslauthdctl down, snmp : STOPPED, spell : OK, stats : OK

However, running it as nagios user on the zimbra server complains about the path:

zimbra-server# su -m nagios -c "./check_zimbra.pl" 
Insecure $ENV{PATH} while running setuid at ./check_zimbra.pl line 32.

Line 32 recites:

7  $zimbra_status_command='/opt/zimbra/bin/zmcontrol status';
[snip]
32 open (ZMSTATUS, "$zimbra_status_command |");

I have a suspicion it might have something to do with suid perl. In fact, following this advice and adding this line to the check_zimbra.pl file,

delete @ENV{'PATH', 'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};

I get the following:

zimbra-server# su -m nagios -c "./check_zimbra.pl" 
Insecure dependency in piped open while running setuid at /opt/zimbra/bin/zmcontrol line 389.

Anyhow, on the zimbra server I have installed the check_zimbra.pl plugin, which is suid zimbra so I can run it from the nagios user:

zimbra-server# ls -la check_zimbra.pl 
-rwsr-xr-x 1 zimbra root 2885 2010-01-11 21:14 check_zimbra.pl

I have modified /etc/sudoers so that the nagios user can run the appropriate zimbra monitoring tool:

%nagios ALL=(zimbra) NOPASSWD:/opt/zimbra/bin/zmcontrol

I am stuck.. is there any other way to run the check_zimbra.pl plugin as nagios user, being able to run the zmcontrol status command as zimbra user..?

Thanks,

On an old GNU/Linux Ubuntu box I see something like

lorenzo@metropolis:~
    $ w
 09:58:18 up 651 days, 19:30,  5 users,  load average: 0.28, 0.30, 0.24

The problem is, I am logged on other three sessions. The number should be four, not five. Any clue why the number of reported users is higher?

Checking lastlog, however, returns a correct value:

lorenzo@metropolis:~
    $ sudo last -ain 7 | grep 'still logged in' | wc -l
4

[edited] Here is the output of who, taken in another occasion but still showing two users, and three reported by w

lorenzo@metropolis:~
    $ who 
lorenzo  pts/0        Dec 28 13:10 (XXX)
lorenzo  pts/1        Dec 28 13:07 (XXX)
lorenzo@metropolis:~
    $ w
 13:11:15 up 651 days, 22:43,  3 users,  load average: 0.49, 0.40, 0.31
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
lorenzo  pts/0    XXX              13:10    0.00s  0.11s  0.00s w
lorenzo  pts/1    XXX              13:07    3:09m  0.13s  0.13s -bash

My paranoid sense is tingling.

[edited] some more commands requested

    $ cat /etc/issue
Ubuntu 8.04 \n \l

    $ dpkg-query -S /usr/bin/w.procps 
procps: /usr/bin/w.procps

    $ dpkg-query -S /usr/bin/who
coreutils: /usr/bin/who

After months of neglect, e-mail flames and management battles our current sysadmin was fired and handed over "the server credentials" to me. Such credentials consist in a root password and nothing else: no procedures, no documentation, no tips, nothing.

My question is: assuming he left boobytraps behind, how do I gracefully take over the servers with as little downtime as possible?

Here are the details:

• one production server located in a server farm in the basement; ubuntu server 9.x probably, with grsec patches (rumours I heard last time I asked the admin)
• one internal server that contains all internal documentation, file repository, wikis, etc. Again, ubuntu server, few years old.

Assume both servers are patched and up-to-date, so I'd rather not try to hack my way in unless there's a good reason (i.e. that can be explained to upper management).

The production server has a few websites hosted (standard apache-php-mysql), a LDAP server, a ZIMBRA e-mail suite/server, and as far as I can tell a few vmware workstations running. No idea what's happening in there. Probably one is the LDAP master, but that's a wild guess.

The internal server has an internal wiki/cms, a LDAP slave that replicates the credentials from the production server, a few more vmware workstations, and backups running.

I could just go to the server farm's admin, point at the server, tell them 'sudo shut down that server please', log in in single user mode and have my way with it. Same for the internal server. Still, that would mean downtime, upper management upset, the old sysadmin firing back at me saying 'see? you can't do my job' and other nuisances, and most importantly I'd have to lose potentially a few weeks of unpaid time.

On the other end of the spectrum I could just log in as root and inch trough the server to try to make an understanding of what's happening. With all risks of triggering surprises left behind.

I am looking for a solution in the middle: try to keep everything running as it is, while understanding what's happening and how, and most importantly avoiding triggering any booby traps left behind.

What are your suggestions?

So far I thought about 'practicing' with the internal server, disconnecting the network, rebooting with a live cd, dumping the root file system into a USB drive, and load it on a disconnected, isolated virtual machine to understand the former sysadmin way of thinking (a-la 'know your enemy'). Could pull the same feat with the production server, but a full dump would make somebody notice. Perhaps I can just log in as root, check crontab, check the .profile for any commands that's launched, dump the lastlog, and whatever comes to mind.

And that's why I'm here. Any hint, no matter how small, would be greatly appreciated.

Time is also an issue: there could be triggers happening in a few hours, or a few weeks. Feels like one of those bad Hollywood movies, doesn't it?

The research lab where I work has been offered a bunch of IBM rack-mountable servers for very little money. The hardware is a bit outdated but it would suit our needs perfectly -- If we can fit one of our customized PCI cards into one of them.

I looked around but just can't find any information on how much space is available for PCI cards. They have been referred to me as "IBM xserie 345" [sic], but I believe they meant "xSeries 345".

Do you have any link to official documentation that can help me? I need to know exactly how big a PCI card must be to fit into a server.

our former sysadmin went from fulltime to 'on demand' and left me with the "task" to administer part of the local network. One of my jobs is changing users' passwords (they can't do it themselves unless they are given the LDAP admin password, for some reason). For what I can understand there is a master LDAP server that is used to authenticate users for a myriad of accounts: ssh, redmine, samba, zimbra, etc.

The procedure he instructed me to follow to change a user's password involves:

• launching LDAP Admin (windows version)
• logging in with a very specific set of credentials (cn=admin,dc=domainname)
• navigating down to the user
• right-click on the user and then, "set password"

Since I don't have Windows, find it quite silly to devote a VM just to change a password for LDAP. I am also quite stubborn myself and I refuse to believe it's the only way to go. I am not familiar with LDAP but I am almost certain that it was never intended to be used this way!

My question: what tool do you recommend to do this job?

I tried LDAPManager for OSX but it does not have the 'change password' button. I tried changing the SambaPassword field (and others..) but to no avail. The former sysadmin said he tried already all available tools and the windows version is the only one that allows you to set a password. [insert WTF here]

What did I try so far:

• phpldapadmin is installed on the server, but I think it's misconfigured since once I log in I cannot even see the correct domain name
• ldapadmin under wine but it's highly unstable

• ldappasswd but can't understand what's going on, it always gives me:

  Please enter your password: ldap_sasl_interactive_bind_s: Invalid credentials (49)

  no matter what I try.

Now, LDAP is somewhat dark magic for me. When I was doing sysadmin work years ago I never had to configure one. Now I don't understand if I'm doing something wrong, if the server is just badly configured or if really the only way to change a user's network password is to depend on a Windows-only tool (kinda refuse to believe that).

So I am asking you all: what do I do? And, does it have to be so complicated? We're just 10 people here, does it really make sense to waste all this time and effort for such an unusable system?

Note: I know there are scripts that are ran every few minutes "to keep the LDAP passwords and other passwords in sync", but I do not have root access to the server nor will be given at any point.