Free for some people just means they are not footing the bill ... maybe

I see the following in the New York times today:

Health Plans Must Provide Some Tests at No Cost
By ROBERT PEAR

Published: July 14, 2010

WASHINGTON — The White House on Wednesday issued new rules requiring health insurance companies to provide free coverage for dozens of screenings, laboratory tests and other types of preventive care.

The new requirements promise significant benefits for consumers — if they take advantage of the services that should now be more readily available and affordable.

In general, the government said, Americans use preventive services at about half the rate recommended by doctors and public health experts.

The rules will eliminate co-payments, deductibles and other charges for blood pressure, diabetes and cholesterol tests; many cancer screenings; routine vaccinations; prenatal care; and regular wellness visits for infants and children. ...

I assume that the reporter no longer believes in the tooth fairy. The article is tailored as news, and placed in that section of the paper (Page A16) by the Times editors. It has a laundry list of wonderful tests and services that no 'right thinking' person can deny are useful and desired

But the suggestion is a 'promise [of new] significant benefits for consumers — if [only] they take advantage of the services' without a corresponding cost for getting there. No hint nor argument is made that such 'medical' services are unavailable for private purchase already

Indeed, at the end of the day, there is no support for the headline writers assertion of 'no cost' and the reporter is well willing to disregard the pesky question of how to pay for this largess. Clearly these tests are not free and when accounts are settled; these costs will either pass through in a rate base, or the provider will exit the market it cannot make money in, or the insurance market will wither and die as 'the government' provides an 'option' that picks up the tab ... . But the problem is -- 'the govenment' at whatever level likewise needs to get the money to pay for such happy healthiness, and from the very same pool of people 'benefitted'

It is not at all clear that the transaction friction of a single govenment payer works at all well, or that having no choice but 'insurance' through government once the private insurers die is a good thing at all. In watching the 'response' of the government to the oil spill in the Gulf, it is patently clear that government 'oversight' has slowed the response, as BP has become risk adverse to the (reasonable) prospect of being second-guessed at every turn, and so is seeking prior governmental approval before acting in the remediation. The ccase can be made that playing 'Mother may I?' has harmed the Gulf more than the prior approach

Do we really think that a central government single point of control is going to react as well and quickly as a local doctor on the scene, when Aunt Minnie is lying, dying under an oxygen tent and needs some immediate surgery? Under the current system, the doc knows that he'll get paid, perhaps only in part of what is billed as a 'list price' for a prodedure, but eventually from the present model

But that is the end game, anyway, right? Vote and mandate 'bread and circus entertainment' ... until the producers all surrender and act to stop being charged for 'free' benefits to the consumers

'The problem with socialism is that eventually you run out of the other peoples (willing to be robbed of their) money'

SELinux other voices

The RHCE in channel of my last post complains I was too hard on him or her. Also that person points out they used a differing approach for building the new policy file, which permits more atomicity in maintaining several policies (here, sorting by daemon). While I invited reply by way of a formal post to that person, it appears that this is their 'final word' ("topic closed") on the matter. As such I note it here for those of you playing along at home:

grep vsftpd /var/log/audit/audit.log | \
   audit2allow -M vsftpd
semodule -i vsftpd.pp
vi vsftpd.te
checkmodule -M -m -o vsftpd.mod vsftpd.te
semodule_package -o vsftpd.pp -m vsftpd.mod
semodule -i vsftpd.pp

More information that is accurate is better than less. Clearly there are many paths to rule generation and maintenance. The takeaway remains: Use, and do not disable, SELinux

Thanks for the feedback

SELinux sanity outline

Rusty Coker mentioned in a recent blog post that he had not found a COLO facility or VM provider that enabled SELinux in its hosts by default. People regularly whine: It's too hard, and I don't need it and disable the SELinux protections. Foo

I call: Bull on the latter As to the former I sent a private email to Rusty, and offered to 'comp' him an instance to break

If anyone knows of a virtual hosting company that runs Xen or KVM virtual machines with SE Linux support then please let me know, I'll write a blog post comparing such companies if there are some.

umm -- I would be embarrased to be a hosting provider which did NOT enable SElinux

Please feel free to set up a 'comp' account at:
http://www.pmman.com/signup/
at the green arrow. Use the [please do not repeat this] 'Offer Code' of: ...

... I repeated the offer at his blog's comment site

And the question came up today in the #centos IRC channel

13:52 Andro1d> orc_orc: how can i recompile a pp from a te ?
13:53 Andro1d> checkmodule -M -m -o vsftpd.mod vsftpd.te gives a lot of errors :-/
13:53 orc_orc> ehh?
13:53 wolfy> Andro1d:
http://wiki.centos.org/HowTos/SELinux [CentOS wiki]
13:53 orc_orc> make a working dir -- say:
mkdir -p /etc/selinux/targeted/foo
and cd into it
13:54 orc_orc> Gather all the selinux noise:
audit2allow -i /var/log/audit/audit.log* -m local > local.te
13:54 Andro1d> hm, I think I'm missing some types in my .te file
13:54 orc_orc> Note the '*' in that prior line, which reads all log files present
13:54 Andro1d> mom...
13:54 orc_orc> Install the selinux-devel package for the needed Makefile
13:54 Andro1d> don't wanna make a "huge" selinux policy :)
13:54 orc_orc> Then run:
make -f /usr/share/selinux/devel/Makefile
13:55 orc_orc> and apply it:
semodule -i local.pp
13:55 orc_orc> Test again
13:55 Andro1d> yop, mompl
13:55 orc_orc> When happy, be sure to save a versioned copy, because SELinux audit file ageing will cause you to forget what was needed in that merge
13:55 orc_orc> For extra credit, amend:
/etc/audit/auditd.conf
to retain a sensible universe of back logs
13:56 orc_orc> '4' is wayyy too small


wolfy (a channel regular who offers reliable answers), pointed to the CentOS secondary source answer in the wiki; this post will also pass into our planet as yet another piece of documention and 'cheatsheet'. You saw a self-described RHCE (and he was proud of it coming into the channel today) doing that whimpering for his mommy as I read him the 'riot act'. I don't care in the least that this is new and 'hard' -- growing and learning new tools is part of the Unix culture, always has been, and always will be. That is why I try to make #centos a learning venue rather than a drive-by 'spoon-feeding' shop

How many times do we need to bang the SELinux drum to get your attention?

Yes, you lazy slogs of alleged sysadmins who simply disable SELinux, I am talking to YOU! yep - words are hard to memorize, but this is a basic 'lather, rinse and repeat' cycle which one can solve experimentally if not predictively from knowledge of what is happening. Run a tail -f /var/log/audit/audit.log if you must to see when the rule set needs to be rebuilt

But stop disabling SELinux and stop making excuses

lost memories

From time to time, "we" 'clean house' and find the black trash bags. It is no surprise to me, of course for and earlier me have done to work of carefully tied packaging closed, and cacheing treasures up in the attic; from time to time, I am instructed to 'get rid of that clutter' as the now grown kids 'will never use those again' I am slow to act on this injunction

The Brio trains, the metal Erector set, the cast lead soldiers and molds, the Duplo blocks, the stuffed animals, Lincoln logs, the McGuffey readers, the arrow and ax heads collected in the fields, have all fallen to head of the queue for disposition over time. Stuffed animals were in the dock this past weekend. At that point, I usually nod silently, carefully re-tie the sack, and set it to one side for a moment. Then my new task is to find a new hiding place for the bag in question after her attention turns to other matters

But a grandchild's mother and the child were delighted with the animal figures from my preservation efforts, even if the spouse was not as well pleased to see 'those old things' again

A few weeks ago, the Brio train set that was set aside in a cardboard box, up in the dark to rest almost two decades ago came out. It moved in with a grandson infatuated with rolling stock and was 'new' again; The Erector set, the melting pot and molds, all gone (not to return with current day safety rules — choking hazard of the nuts and bolts, heavy metal fumes). I am on the lookout for a replacement McGuffey reader set (that friend of books that taught me to read upstairs in a quiet room as the adults 'talked' downstairs), so I can 'seed' a room for young visitors

The flints and shaped stones? I was not attuned to their disposition occurring; a 'sharpie' sweet-talked a sale for a pittance from a elderly family member when 'cleaning up' prior to closing down a house before sale. That lot of childhood treasures also carried out the door the minnie balls I dug from the earth at Gettysburg

Entropy won a round that time; I know we'll battle again.

---

[An earlier version of this appeared at Victor Niederhoffer's Daily Speculations, which aggregator I recommend]

Debian mkfs is working again

It's been a long June. I noticed early on that an update in Debian testing had moved mke2fs from one package to another without getting all the library dependencies right. As such I spent June without the ability to lay down a filesystem on a new partition with the 'proper' tool. Part of my series on logfile reading includes a task to review the 'percent full' for each partition (and to relocate or clean out fat ones) to avoid running out of room in a self-inficted denial of services attack

I tried the obvious fallback to build a new filesystem: busybox but the version found in Debian Testing was lacking a needed build time switch. I filed the bug, and considered a local patch, or perhaps whether to rebuild of part of the chain needed to fork mkfs for a bit, but my need for space to reorganize a host's files was not that great nor urgent. Just pesky each day to see

I knew from reading the bug reports that the fix had been committed and 'ageing' in the Debian fashion to its move from an Unstable 'nightly' to a mildly tested (or at least not black-balled) state and promotion into Testing

nfs2:~# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
ksysguard libdevmapper1.02.1
The following packages will be upgraded:
bsdutils e2fslibs e2fsprogs iptables iso-codes libblkid1 libcomerr2
libenchant1c2a libffcall1 libmime-tools-perl libnetpbm10 libss2 libuuid1
lockfile-progs mount mutt netpbm shared-desktop-ontologies util-linux
19 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 9,841kB of archives.
After this operation, 115kB disk space will be freed.
Do you want to continue [Y/n]? y
...
nfs2:~#

I've been running repository data update operations daily .. the Debian approach is more measured in its pace than we use with CentOS, and I think we may have something to learn there. It is a rare package update that cannot wait for a daily repo data update, push and mirror overnight in our space, and it would avoid much confusion to casual sysadmins

Those bolded packages in that clutch of upgrades looks promising ...

nfs2:~# mkfs /dev/sda12
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
237568 inodes, 949835 blocks
47491 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=973078528
29 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
nfs2:~# date
Thu Jun 24 10:13:17 EDT 2010
nfs2:~#

Lovely; I'm back in business

Reading the logs, part 3 -- Run your updates

It looks like I'll be writing these for a while as I clean up logfile noise. The earlier pieces are here and here. I say 'noise' here because they are not false positives, but neither are they material, just more a nuisance

One the things every admin who reads log files sees are automated scanners looking for exploits in 'canned' packages that were installed but have not been updated, either because the admin for a given machine has neglected to run updates, because it is not a publicly known exploit, or because the upstream has not yet addressed the matter.

A pattern that has emerged with our PMman with a data center with large contiguous swaths of IP space (and hosts scattered in assignment in that relatively compact range, said hosts reporting to me centrally) is as follows. The hostile exploit scanners are not even trying to be subtle any more -- they simply march sequentially through IP ranges, and inventory if a given weakness is present on every host to which they connect

Today, I focus on one sample report stanza:

--------------------- httpd Begin ------------------------

Requests with error response codes
400 Bad Request
HTTP/1.1: 1 Time(s)
403 Forbidden
/index.html: 1 Time(s)
404 Not Found
/cms/e107_files/e107.css: 1 Time(s)
/db/e107_files/e107.css: 1 Time(s)
/e107/e107_files/e107.css: 1 Time(s)
/e107_files/e107.css: 1 Time(s)
/forum/e107_files/e107.css: 1 Time(s)
/index.php: 1 Time(s)
/manager/html: 1 Time(s)
/portal/e107_files/e107.css: 1 Time(s)
/site/e107_files/e107.css: 1 Time(s)
/web/e107_files/e107.css: 1 Time(s)

---------------------- httpd End -------------------------

and apache can handle this trivially:

#
# file: noexploit.conf
#
# send scanners off to see the wizard
#
Redirect permanent /cms http://127.0.0.1/
Redirect permanent /db http://127.0.0.1/
Redirect permanent /e107 http://127.0.0.1/
Redirect permanent /forum http://127.0.0.1/
Redirect permanent /manager http://127.0.0.1/
Redirect permanent /mysql http://127.0.0.1/
Redirect permanent /phpmyadmin http://127.0.0.1/
Redirect permanent /phpMyAdmin http://127.0.0.1/
Redirect permanent /portal http://127.0.0.1/
Redirect permanent /site http://127.0.0.1/
Redirect permanent /user http://127.0.0.1/
Redirect permanent /users http://127.0.0.1/
Redirect permanent /web http://127.0.0.1/
#

The obvious next step is to package deployment hardenings, and add them to a local RPM repository so that simply running updates, as with yum will get the current best approaches on hardening, en masse, on all the servers

Reading the logs ...

I see the following from logwatch in the overnight log file review:

 --------------------- httpd Begin ------------------------

 Requests with error response codes
    404 Not Found
       /crossdomain.xml: 1 Time(s)

 ---------------------- httpd End -------------------------

and so I go digging:

[root@centos-5 httpd]# cat error_log
[Sun Jun 06 04:02:04 2010] [notice] Digest: generating secret for digest authentication ...
[Sun Jun 06 04:02:04 2010] [notice] Digest: done
[Sun Jun 06 04:02:05 2010] [notice] Apache/2.2.3 (CentOS) configured -- resuming normal operations
[Mon Jun 07 14:20:39 2010] [error] [client 127.0.0.2] File does not exist: /var/www/html/crossdomain.xml

Sure enough. It looks as though some piece of Flash code is hoping to 'leverage' a cross-domain permission to include something I may not have intentionally intended to allow.

See the note at: http://kb2.adobe.com/cps/142/tn_14213.html

For the sake of argument, assume you HAD to web view as root, as say with an operating system that required you use a browser front end to access system updates. Assume also that you improvidently viewed a 'seeder' of bad things that WROTE a hostile crossdomain.xml for later use by a second piece of hostile Flash to 'reap'

Oops ... game over