David Michael Noriega

I run primarily Linux but I do have a Windows server for those who need a bigger Windows machine to work on and make it available via remote desktop. To have it play nicely with the rest of our systems, I also run a domain via Samba. While I don’t like roaming profiles, my users are used to it and the messages about unable to load a profile bother them.

Recently a user needed access to the Window server but then had weird access denied errors when trying to logon. I had them in the remote desktop group and the only messages in the logs were with loading errors about the profile.

The error shown was “Group Policy Client Service Failed The Logon.” Searching show this was a symptom of a corrupted profile and thus I deleted it, but then after that it was never regenerated and thus the missing profile messages every time since. 

Thanks to a guy named Steve on the mailing list, I was able to determine what was going wrong. Within the registry, Windows stores some info about the profile, in particular is the location on the server. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowNT\CurrentVersion\ProfileList stores a list of user SIDs and they key CentralProfile was wrong. Deleting the entry from ProfileList fixed the profile errors and now its all good.

[Samba] Windows Profiles Not Being Created

I had setup webdav access for a user to allow them the ability to upload and edit their web application and as part of that setup, they had their own cgi-bin. Not normally an issue, but as a way to prevent any security issues, I’ve kept SELinux enabled. Turns out this was causing a problem with uploading files into the cgi-bin directory. Sadly there wasn’t an easy boolean value I could set for this but the audit2allow command came in handy.

Now be sure you check the module code before enabling it to ensure nothing shady is there. Simply running audit2allow on all messages in the audit log would build a module that can include permissions to allow potential hacks through. I saw some weird permissions that I knew were not needed to allow webdav access to cgi-bin and removed them from the module file. Here is the module that finally allowed access to the cgi-bin directory:

module webdav-cgi-bin 1.0;

require {
type httpd_t;
type httpd_sys_script_t;
type httpd_sys_script_exec_t;
type httpd_sys_rw_content_t;
class dir { write remove_name create add_name };
class file { write create unlink execute setattr};
}

#============= httpd_sys_script_t ==============

#!!!! This avc is allowed in the current policy
allow httpd_sys_script_t httpd_sys_rw_content_t:file execute;

#============= httpd_t ==============

#!!!! This avc is allowed in the current policy
allow httpd_t httpd_sys_script_exec_t:dir { write remove_name create add_name };

#!!!! This avc is allowed in the current policy
allow httpd_t httpd_sys_script_exec_t:file { write create unlink setattr };

Now this allows the web server read/write access to cgi-bin, which might be an issue, but I do protect webdav access behind access controls and SSL.

Seeing this news is disappointing. I wonder if they understand the simple premise that the weakest point in any defense are the openings. This would include backdoor.

White House close to backing FBI’s wiretap backdoor proposal, says NYT http://www.theverge.com/2013/5/7/4310936/white-house-close-to-backing-fbi-internet-wiretap-proposal

In tinkering with setting up a kickstart script to get a basic workstation installed just like I want I decided to revisit the authentication issue related to certificates with an MD5 signature. Thankfully there is a workaround to enable MD5 support in the nss package that worked for me. Simply add ‘export NSS_HASH_ALG_SUPPORT=+MD5′ to /etc/sysconfig/init and reboot. Thanks go to @NewLifeMark and this blog posting.

CentOS just released 6.4, so I decided to update the office server and as it was the end of the day, left it at that. Bad form on my end as I come in the next day to find I’m unable to connect to the samba server. Checking the logs I see samba is unable to connect to LDAP via TLS. I also quickly discover that the server itself is unable to get user information. First guess was to check the ldap server, but its running fine.

Second guess is to try ldapsearch from the office server and I get my first hint. Ldapsearch was not accepting my Certificate Authority and was giving a bad signature algorithm error. Researching that lead me to the following bug report: Unable to authenticate to legacy LDAP server due to “not secure” certificate signature.

It becomes clear that due to the decision at Mozilla, who develop the NSS(Network Security Services) library to stop accepting MD5 hashes is the root issue. I then set out to downgrade NSS to pre 6.4 release. The following packages were the ones I downgraded to get my system working again: nss nss-sysinit nss-tools nss-util nss-pam-ldapd mod_nss.

Now some may ask why not just upgrade your certificates to a newer and thus more secure signing algorithm? Well to anyone who has ever worked with OpenSSL and creating certs for a multitude of servers, its not a trivial task. I’ll put it on my todo list, but for now its at the bottom.

Thanks to following blog post by Matt Micene that was the break in this case.

I was reading Adria Richards’ blog post about her experience at PyCon, and while fascinating, its the inevitable comments that follow that leave me disappointed. As a geek I understand the cliquish nature we have in groups and our use of language, in this case sexist jokes, as a way to strengthen those ties but on the flip side that only serves to set boundaries that exclude. Maybe, and only for the sake of argument, maybe this would be acceptable in a more private setting, but this was a public event. A developer convention where professionals come to join in their community and learn and network and otherwise be friendly. I also stress the professional aspect as its been detailed that these individuals were wearing their company logo which should immediately put one into the state of mind that you are representing that company.

Also to those who some how blame Adria for an individual being let go from their company is absurd. That is a decision entirely left up to the company’s management in response to their employee’s behavior. If this incident had happened within the setting of the workplace and had the same outcome, and somehow became public, would such an argument hold up? I don’t think so.

As for the public outing of these individuals, I’m still on the fence. It should be expected now in today’s social media world that any photo taken will end up online. Should Adria have send a private message to the PyCon crew? I dont know. But should she just have sat there and taken it? No, not at all and by making the picture public, these individuals are then left to be disciplined by their community. Any action by their employers is between them and should be left there.

So be mindful of your surroundings and be more inclusive, you’ll make more friends that way and that is always more fun then some joke.

Cypherpunk rising: WikiLeaks, encryption, and the coming surveillance dystopia

The dkms version of the Nvidia driver is a great convenience, yet it usually means you wont have the latest version and when the kernel updates, that can be a problem. Like Today.

Running CentOS 6 on our workstations and decided time to update packages and I hoped dkms wouldn’t let me down, but it did. So boot into run level 3 and remove dkms and the dkms nvidia driver to make way for the latest version. Its normally a straight forward process, yet Nvidia can mess up the xorg installation, like it did for me. Some how libwfb.so was missing, so the Nvidia driver will install its own version.

This doesn’t work as you’ll get a message about unknown symbol PictureScreenPrivateIndex. Turns out for some installations that don’t have libwfb, Nvidia brings its own, yet since I’m supposed to have it, this led to trouble. The quick fix is to reinstall the right package. Use yum whatprovides */libwfb.so to find that xorg-x11-server-Xorg is the correct package and yum reinstall restores libwfb. Install the Nvidia driver via the script as usual and you should be good to go.

I’m not sure if its a bug or a feature but something I ran into when signing a certificate request with our self signed certificate authority. The new system is running CentOS 6 and when I tried to sign the request, it would fail saying the state name didn’t match. It prints them both out and as far as I can tell, they are the same. But something that bothered me gave me a clue. It would print out Distinguished Name like so:

stateOrProvinceName :ASN.1 12:’Texas’

That ASN part made me think and this bug post gave me an idea. As I didnt want to go playing with the policy setting, I read through the openssl.cnf file for more details and I came upon the string_match setting. My CA had been created using the nombstr setting while in CentOS 6, it was set to utf8only. Editing openssl.cnf on the new system and creating a new request fixed the problem and now the DN looks like so:

stateOrProvinceName   RINTABLE:’Texas’

So just be aware of this setting

Slashdot: Twitter Starts Withholding Rather Than Deleting Copyright-Infringing Tweets

Such a simple idea and don’t know why they didn’t do this to begin with. Though I would much rather see something like a filtering system as opposed to just logging the take down of a tweet.