The Full Disclosure folks say that vulnerabilities should be disclose immediately. Their arguments have some merits. The Responsible Disclosure folks say that the vendor should have n number of weeks to get a patch out, then it goes to Full Disclosure. That has some merits as well, but the trouble is the public doesn’t know there’s a problem during the n weeks. The calculation is a balance of how many people will be protected vs. how many people will be harmed.

It occurs to me that a third way, call it ‘Informed Disclosure’ for now, would be to:

Make an announcement that x number of vulnerabilities have been discovered in the foo feature of bar and list known workarounds.
Wait the n number of weeks
move to Full Disclosure

as a way to avoid the problem with Responsible Disclosure but still give the vendor reasonable time to react. e.g. ‘Informed Disclosure’ may say:

ISSUE-001: Acrobat Reader has a vulnerability with JavaScript objects embedded in documents that can cause a smashed stack. Disable JavaScript in Acrobat Reader to avoid this problem.

and then send Adobe the exploit code, which will be published in 45 days. This also removes the illusion of potential blackmail from security researchers, because the public has on-record information that the disclosure will be published, regardless of the action or inaction by the vendor.

Surely others have taken this approach, but I can’t find a name attached to it — anybody?

Goal: TLS, no chroot-ing, no anonymous,Passive Mode.

Setup:

First cd to /etc/pki/tls/certs and run ‘make vsftpd.pem’.  This will let you create a certificate.  ‘chmod 600′ the certificate.

Then, go edit /etc/vsftpd/vsftpd.conf .  Here’s a working configuration:

anonymous_enable=NO 
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
dual_log_enable=YES
connect_from_port_20=YES
xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
chroot_local_user=NO
ls_recurse_enable=YES
listen=NO
listen_ipv6=YES
pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
rsa_cert_file=/etc/pki/tls/certs/vsftpd.pem
pasv_min_port=50000 
pasv_max_port=50064
require_ssl_reuse=NO
seccomp_sandbox=NO

Now go edit /etc/sysconfig/iptables. Because of TLS, the standard nf_conntrack_ftp module isn’t going to work. It would be nice if somebody enhanced that to know about the .pem file. Here’s a working set of rules that matches the above (arbitrary) port range:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-A INPUT -p tcp --dport 50000:50064 -m state --state RELATED,ESTABLISHED,NEW -j ACCEPT

Then restart your vsftpd and iptables services and you should be good to go.    Filezilla will work with its defaults.  For lftp, you can create a .lftprc file like this:

set ssl:verify-certificate false
set ftp:ssl-auth TLS
set ftp:ssl-force true
set ftp:ssl-allow yes
set ftp:ssl-protect-list yes
set ftp:ssl-protect-data yes
set ftp:ssl-protect-fxp yes

Solution: your old /etc/sysconfig/nfs file is messing up the NFS server. rpc.idmapd is no longer needed. (man nfsidmap). Run:

mv /etc/sysconfig/nfs /etc/sysconfig/nfs.rpmsave
mv /etc/sysconfig/nfs.rpmnew /etc/sysconfig/nfs
systemctl restart nfs-server.service

And if your client is running autofs, restart that on the client as well. Now NFS should work again.

With an MBR Partition Table it was easy enough to just nuke the beginning of the drive (adapt sdz for your drive), ala:

dd if=/dev/zero of=/dev/sdz bs=1M count=1

and be on your way.  Wouldn’t it be lovely if dd understood negative indexing and you could just say:

dd if=/dev/zero of=/dev/sdz bs=1M count=-1

and be done?   Alas, it’s not meant to be.

One way to do this is to simply use ‘dd’ to write zeroes to the entire device:

dd if=/dev/zero of=/dev/sdz bs=8M

This is entirely effective, but with today’s 2-3TB drives, this can take quite a while.  You can start it and go home for the night, but if you’re not paying attention, a dd that doesn’t finish can cause you frustration and embarrassment.  Since we only need to write 34 512-byte blocks, really what we need to do is to calculate the size of the drive and find the correct blocks to overwrite.

In the recent past, people will have told you to run fdisk, look for the cylinder/heads/sectors/clusters information, apply a mathematical transform, and plug that into ‘dd’.  Besides being a pain, fdisk doesn’t even claim to support disks over 3TB.  Before the floods, those were becoming quite common.

Fortunately, Linux’s sysfs will report a block device’s size, conveniently in 512-byte block units (though that’s not necessarily obvious in context).  For instance:

# cat /sys/block/sdz/size
3907029168

shows me a 2TB disk’s actual size. I’ve looked at a 3TB disk, and fortunately (for now at least), even though the drive really uses 4k blocks, linux is still reporting in terms of 512-byte blocks.  This helps since GPT size is defined in terms of 512-byte blocks, but I wouldn’t count on sysfs to maintain this convention forever.  At some point nobody will have any 512-byte block drives and somebody will decide it’s silly to keep reporting fake block counts in sysfs.  Sanity check before blowing away drives, eh?

So, now that we know that we have the right value with the right units, it’s simply a matter of taking out the first GPT label:

/bin/dd if=/dev/zero of=/dev/sdz bs=512 count=34

and then the second (3907029168-34=3907029134):

/bin/dd if=/dev/zero of=/dev/sdz bs=512 count=34 skip=3907029134

To make sure linux understands what you’ve done here, run:

partprobe /dev/sdz

and make sure partprobe doesn’t insist upon a reboot to get the kernel straight about this (so far I haven’t found a way around this).

Verify with other partition information tools that might be relevant, e.g.:

zdb -l /dev/sdz

for ZFS.

TL;DR : for convenience, here’s a perl script that automates the above process.  Call it as:

perl zero-gpt.pl /dev/sdz

or, simply:

perl zero-gpt.pl sdz

As of this writing, the script simply prints commands for you to run – it’s not brave enough to run them itself.  So, check them before you run them.

There might be a port available, but not stock on machines, and if your machine is inside a restrictive firewall, it might be hard to get.  In a pinch, the following seems to work fine:

while /bin/true ; do clear; date; echo; ps ax | grep send; sleep 5; done

Where ‘ps ax | grep send’ is an example of the command to be used. All the rest is boilerplate. Adjust the ’5′ as you would the ‘-n’ parameter.  No doubt a simple shell script could be made to act like real ‘watch’.

1. md-raid mirror
2. LUKS encryption
3. ZFS zvol

This works nicely as it’s easy to split off an encrypted backup disk to take offsite, but since ZFS encryption hasn’t come to Linux yet, it’s still a stack of technologies to manage.  My backup set gets ever larger, so to expand the backups capacity, I bought a pair of Hitachi 3TB SATA drives.  Assuming:

• the old drives were sdc and sdd
• the new drives are sde and sdf
• the md mirror is md3
• the LUKS volume is called backup and presents as dm-0
• the zfs pool is called ‘backup’

to expand the stack:

1. mdadm –add /dev/md3 /dev/sde
2. mdadm –fail /dev/md3 /dev/sdc
3. mdadm –remove /dev/md3 /dev/sdc
4. wait for rebuild to finish (cat /proc/mdstat)
5. mdadm –add /dev/md3 /dev/sdf
6. mdadm –fail /dev/md3 /dev/sdd
7. mdadm –remove /dev/md3 /dev/sdd
8. wait for rebuilt to finish
9. mdadm –grow –size=max /dev/md3
10. cryptsetup resize backup
11. zpool online -e backup dm-0

and then run ‘zfs list’ to ensure the size is updated.  Conveniently, this can all be done without taking any of the filesystems offline.

The biggest challenge is the integrated ATI HD 6550D graphics.

Download the latest .fc16 build of Linux 3.0 from koji for proper KMS (kernel mode setting) support. Then download the latest ATI Catalyst driver from AMD. The version in RPM Fusion isn’t new enough as of this writing, nor is the xorg-x11-drv-ati build in koji new enough (the PCI ID’s are in their git tree).

That’s enough to get the system up (oh, systemd, why don’t you give me any virtual consoles when X startup fails?).

I’m stuck at 1600×1200 resolution at the moment. This display does 1900×1200, so it’s blurry. I haven’t yet found a way around this.

Performance isn’t yet screaming ‘magical’ – on some tasks it’s faster than the Core2Quad it’s replacing (maybe the faster memory?) but on others it seems a bit slower. Probably not much is tuned for it yet – this is really early in the adoption curve.

Update 2011/08/21: Sound is now working with the 2.6.40 kernel update.  Haven’t tried graphics yet, as I put an nVidia card in the machine after having a shifted video problem I couldn’t resolve with the video.

On the Nexenta/Solaris machine, for zpool ‘storage’:

zfs set aclinherit=passthrough storage/shared

zfs set sharenfs=on storage/shared

/usr/sun/bin/chmod A=everyone@:read_data/list_directory/write_data/add_file/append_data/add_subdirectory/read_xattr/write_xattr/execute/delete_child/read_attributes/write_attributes/delete/read_acl/write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow /storage/shared

Now install idmapd on the linux side and start it (rpcidmapd service on Fedora/RHEL/CentOS, libidmap and the nfs service on SuSE) and mount it with these options:

mount -t nfs4 -o rw,intr,hard,proto=tcp,port=2049,acl storage-server:storage/shared /mnt/shared

or set up your automounter to use similar options.  Now, all users can do everything to the share.

note: Comments are off until I get a better blog. Please e-mail me any corrections and I’ll add them.

/usr/bin/curl http://www.nasa.gov/ram/35037main_portal.ram | /usr/bin/head -1 | /usr/bin/xargs mplayer

If the URL above changes, look for the ‘RealPlayer’ option at http://www.nasa.gov/ntv for a new .ram file.

At issue in Warshak’s e-mail flap was a 1986 law that allows the government to obtain a suspect’s e-mail from an internet service provider or webmail provider without a probable-cause warrant, once it’s been stored for 180 days or more. The appeals court said Tuesday that this part of the Stored Communications Act is unconstitutional.