Note that I said "cost... with overhead". As a rule of thumb, you figure the true cost of an employee to be 2x what the employee is paid in salary, when you take into account equipment, social security payments, benefits, training, travel expenses, office space rental, etc. So a person who makes $50,000 a year (~$25/hr) has a total cost to the employer of $100,000 a year (~$50/hr).
I've worked on some government contracts, and in my opinion a big part of the problem is in the GSA schedule rate structure that the Federal uses for contractors. It is much more profitable for a contractor on a government project to put many junior people on a project rather than a few senior people, for the same amount of revenue. For instance, a junior developer may cost a contractor $50/hr with overhead, but the contractor is able to bill the government for that junior developer at $150/hr., a spread of $100/hr. A senior developer may cost $100/hr with overhead, but can only be billed to the government at $175/hr, a spread of only $75. Furthermore, the contractor can bill more hours of junior time than senior time under a given budget cap, compounding the effects of the greater spread. Thus, the incentives for contractors are to use as many junior developers as possible on a project, to increase the profit margin.
Unfortunately, It's a rule of thumb in this industry that a few good programmers are a lot more productive than many unskilled ones. The result is that many government IT projects are shoddily built by well-meaning but inexperienced developers who are put in that position by a contracting structure that fails to recognize the realities of the IT industry. Contractors are just responding rationally to the incentives that are presented to them.
These numbers are examples -- in fact the situation may be even worse. Federal government contracts vary in their rate structures, and many are stingier than this. It may well be impossible to bring on a senior developer as a subcontractor because the maximum hourly rate that the government will pay on a project is lower than the cost of the senior developer.
A prime contractor that I worked with staffed a large WebObjects project for the Department of Defense with a dozen or so low-paid, fresh out of community college drones. Every six months -- when a project review was due -- they would bring us on board as subcontractors for six to eight weeks. In that time, two or three of us would take the code base from where it was four months ago and bring it close enough to the required progress to get the contract renewed, and then the prime contractor would say "goodbye" and toss us out. Four months or so would pass by, with their people making little meaningful progress, and we would get a panicked call for six or eight weeks of more work to get by the next project review. (Did I mention that the prime contractor didn't pay the bills for one set of work until they needed us for the next project review? It got so bad that at one point we had to treat them as though their credit rating was zero, and demanded that payment for each week's worth of work be deposited in an escrow account before we would continue.)
By the way, this rate structure is not unique to government IT projects. Other types of government projects display the same professional services rate structure. When I worked for a (then) Big Six accounting firm as an economist, most consulting projects for corporate clients were staffed with a ratio of one partner and two or three senior managers to six or eight associates. However, the Federal government group was staffed with a ratio of one partner and one senior manager to twenty or so associates. I talked to the senior manager, and he told me that (a) the associates in the government contracting group were paid much less than we were on the corporate side since they billed out at a lower rate, and (b) the only way they could make money was to use lots of cheap associates because senior people could only break even at best at government rates.
Ya know, it'd be nice to see a GSA person squirm over this sort of thing in front of Congress some time. Then again, Congress may be part of the problem, as they'd rather generate lots of jobs for constituents, instead of a few.
AMEN! I distinctly regret that I don't have mod points right now. I have an ABD in Economics and years of work experience doing econometrics, and this analysis nails how the MTBF calculation is done exactly.
One quibble I have (more with the HD manufacturers, not crmartin) is that HD have mechanical components (spindle, actuator, etc.) that are subject to wear. As a result, MTBF calculations that are appropriate for solid state electronic equipment not subject to physical wear are likely inappropriate for HD's.
Version control definitely belongs in the filesystem. Clearcase may have a lot of implementation uglies, but as a concept it clearly works. Filesystems manage files, and that should include managing file versions.
One place to look for (sort of) file system versioning support is Subversion, an Apache-licensed replacement for CVS. You can mount this via webdav_fs, and you get automatic versioning that works with just about any application, although right now you need to use a separate client to get access to older versions of the files. Still in alpha, but very stable and worth checking out.
Unfortunately, Assimilator won't work for installing Mac OS X as there are hard linked files that Assimilator won't handle properly. Use a combination of Netboot and ASR, or Netboot and Mike Bombich's NetRestore.
From your description and your web site, what you need is not "version control" or "source code management" or "configuration management" software (which is what cvs or subversion provide), but a "content management" system, which contains editorial workflow, publish/unpublish capability, probably the ability to generate static pages, be a web services provider, etc.
My understanding is that a journalled FS records every file block allocation and deallocation on the volume in a separate journal. This way, if an operation does not complete (say, due to a power failure), the disk can be restored to a known consistent state very easily. A consistent state is one where no blocks are allocated that should not be, and no blocks that are in use are listed as unallocated.
Softupdates does a partial re-ordering of operations so that all allocations happen before deallocations. Thus, in the event of a crash there can never be any blocks that are in use but marked as unallocated. The only possible inconsistency is that there may be blocks that are unused but marked as allocated. In the event of a crash, no fsck is performed as a part of the boot sequence, but a special background version of fsck is run to find any blocks that unused but marked as allocated and mark them as unallocated, which is a safe operation.
Comparing the two methods of operation, a journalling FS pays a speed penalty under normal operations, as it needs to do two writes to the volume for every write access from the application, one to write the journalling data and one to write the actual write. However, on a restart after a crash, the journal is just used to roll back the volume's allocations to a known good state and the OS continues on its merry way.
FFS with softupdates is faster under normal operations, as there is only one write to the volume for every write access from the application. However, in case of a crash there is the potential for a large quantity of disk blocks that will need to be scavenged, thus making the volume look like it has less free space than it actually has, plus the background fsck needs to run and fix up the allocations.
Read the Ganger and Patt and McKusick papers linked to in my original post for more details.
JFS, other journalled file systems, and Softupdates have the same goal -- keeping file metadata structures consistent on the disk. JFS does not attempt to maintain file data integrity in the event of a crash -- that is the job of a DBMS. Go and read the web page on JFS from IBM that is linked to in the original posting.
Granted, journalled FS's and softupdates go about things in different ways. Softupdates trades off potentially increased disk space usage and higher disk and CPU activity after a crash (performing the background, reduced set of checks in fsck) against a smaller relative performance penalty vs. a non-journalled FS in normal usage as compared to a journalled file system.
My own $0.02 is that this is a nice scratch-the-itch, check-the-box-for-PHB's addition, but for most normal usage softupdates is a better choice. See the papers by Ganger and Patt and McKusick for more details. (Links copied from the OpenBSD FAQ pages.)
This is still not adequate -- and is (in some ways) worse than nothing. Having managed a lab of student computers back when I was a grad student, often times people will simply sit down at an otherwise unused computer and start typing in URL's. If the attacker installs the software (not requiring a reboot) on a machine and walks away, the next user and any other users who use it without a reboot will still be vulnerable. The keystrokes can be recorded by sending them to an SMTP relay or open FTP server.
This is worse than nothing because if the machine is rebooted then you have just lost any chance at doing forensics on the attack.
There are far better solutions available. First, do NOT allow user software installations -- this should be a part of the TOS for such a lab. This in turn allows you to lock down the machines very tightly. Downloads can still be allowed to a user's network account or floppy or zip disk or USB keychain device.
In a managed environment such as a university, require students to log in to computers with campus-wide accounts. Win2k and XP, Mac OS X, and most unices support Kerberos logins, which are becoming widespread on campuses. This gives students their own home dirs automatically, with saved prefs, etc. It also allows much easier forensics on attacks as well. If you want to allow public access, post a public login to an account that has zero privileges on the wall of the lab.
By going this route, you can then use netbooted machines without internal hard disks, vastly simplifying maintenance and system administration. Netbooting is not always easy to set up, but the payoff is well worth it in such lab environments.
Apple's version of OpenLDAP uses NetInfo as its backing store -- the apple.schema file merely exports the contents. Go to a Mac OS X Server machine and look at the values it puts into NetInfo. This will give you examples of what you need to put into the corresponding LDAP server entries on your Linux server.
Probably easier is to just use the LDAP values you already have in the RFC 2307 schema for your Linux machines, and set the Mac OS X machines to use the RFC 2307 schema by using the Directory Access application.
I'm a curriculum developer for Apple's Technical Training and Certification department, and I also act as the backup sysadmin for our Reston, VA training center. All of our courses are hands-on using serious equipment, with an iBook laptop and a G4 tower at each student station, along with a G4 tower for the instructor and possibly also (depending on the class) an XServe rackmount, a Windows 2000 Server, and Solaris servers, all networked together.
The classes run three to five days, each day covering on average three chapters. Each chapter consists of an instructor presentation for about 30 minutes, followed by a student exercise that runs between an hour to two hours. As you can see from the time involved, our approach definitely emphasizes the hands-on aspects.
I can tell you as one of the people who both writes and teaches Apple's courses, most people will zone out if they have to listen to the instructor for more than 30 minutes. At the technical training level, I can't imagine sitting through a straight lecture class for a whole day without a hands-on piece, and really retaining very much of the content.
--Paul
Paul Suh Curriculum Developer Technical Training and Certification Apple Computer psuh at apple dot com
One thing that all of the various "quality assurance" regimes miss entirely is the value of being able to make mistakes. Risk-averse managers love this "zero defects" kind of environment, because they like the predictability. However, for the organization in a rapidly changing environment, such predictability is often deadly. Achieving the goals takes too long, and by the time you have perfected a process it's obsolete. Customers have moved beyond what you are doing and demand something else. Your perfect buggy whip is no longer useful in an age of automobiles.
Six Sigma and the like were developed in a manufacturing environment, where the same processes are used for years, and there is time to get it perfect. In the IT industry, two or three years yields a radically different environment. People need the room to take risks in order to deal with such a dynamic environment. The corollary is that in taking risks, sometimes you roll snake eyes and crap out. People make mistakes and if you focus only on the down side, you miss out on the greatly increased upside that comes from taking those risks.
Six Sigma in the IT department sounds like a loser. In IT, you want a management style that is looser and and more free-flowing, able to shift quickly, and not stuck on not making mistakes. (Perhaps the biggest mistake to learn from would be to try to apply Six Sigma to your department!)
One of the best things that you can get out of Fowler and Sadalage's article is some idea of the benefits that an object persistence/database abstraction layer can give you. I work with WebObjects, which comes with the Enterprise Objects Framework, a powerful, mature object persistence layer. Think of it as entity Enterprise Java Beans, except that it's a lot lighter in weight at runtime since everything happens in the same address space, along with about 5 years maturity over entity EJB's and very powerful relationship management.
This gives you the ability to let most of your developers works solely with the object model, and encapsulates things like calculating an age from a birth date and today's date or a full name from first name and last name without polluting the database with miscellanea. Only one or two or a specified small team of people need to be concerned with the design of the database and writing SQL. All of the other developers can just use the Enterprise Objects and not worry about it.
However, this brings me to another point -- all of the successful WebObjects projects that I have seen share one thing in common: a highly skilled architect who has a solid understanding of not only the development process but also how databases work. A good developer teamed with a good DBA is no substitute for one master artiste in this case, as the master can know how to create an object design that meshes precisely with the database to optimize performance and ease of development, as well as making it relatively easy to create the UI.
In fact, a sign of a well-run WebObjects project is that for the first week or two, most of the developers are sitting on their hands or taking long lunches or reading Slashdot. During this time, however, the senior person or two is taking the time to get the underlying data object model right. Only when that is solid does the manager unleash the rest of the troops.
Another factor involved in using NFS with Windows clients is the security model involved. To expand on Jeremy Allison's excellent comment, the NFS security model relies totally on the UID at the client. Since there is no native concept of a UID in Windows (plus the fact that the Win9x branch doesn't have good user privileges separation in any case), this means that you need a separate login from the Windows PC to the NFS server, using a system known as PC-NFS originally created by Sun. There is an open source pcnfsd daemon that will handle this at the server end, but the client piece is not free, and the whole thing is a PITA to set up, and is one more thing that can go wrong on a fragile Windows client system. Much better to use Samba on the server and not have to rely on yet another skanky layer. (Been there, done that, have the therapist bills to prove it:-P)
FWIW, the Mac OS up through version 9.2 has pretty much the same set of issues. Mac OS X, being Unix-based, has NFS server and client support natively.
On Mac OS X, the password is stored as a standard Unix-style crypt hash with eight significant characters. It's no more or less secure than most other Unix-style systems that use this system -- this is reasonably secure if you use a solid password. Upper and lower case, numbers, punctuation, etc. I'd personally prefer that it take into account more significant characters, but "this will be covered in a later release". Using the OpenLDAP-based password server from Mac OS X Server gives you 255 significant characters via SASL, but this isn't usable in the case where you want encrypted disk images the most, on a laptop away from any network.
A pretty good way to make a difficult to crack but easy to remember password is to string together two words with some punctuation in between. E.g., my old (now defunct, so don't bother trying it) Compuserve account password, "knife:other". On Mac OS X, this reduces to "knife:ot" which is easy to remember but hashes to something pretty difficult to crack by brute force.
One more thing -- people have been commenting/asking about the speed of access. The algorithm for AES-128 on MOSX 10.2 has been heavily optimized. There is basically little or no additional overhead when using an encrypted disk image vs. an unencrypted disk image.
The underlying AES-128 encryption is part of the Darwin distro. Look in the Darwin sources under:
src/Security/AppleCSP/AES/
This still doesn't really address the whole question -- if there's some back door somewhere higher up the stack in the disk mounting code, you won't find it here, but it's part of the solution. Validate the AES-128 code, then treat the encrypted disk image as a black box (using a simple password, without loss of generality) and see if you can decrypt the image by hand or using a util that you write yourself.
OK, I work for Apple so you really can't fully trust me on this, but I certainly don't know of any intentional back doors in this code.
This is actually something that is covered in the new Mac OS X Administration and Integration sysadmin technical training course from Apple that will be going live in January. As the author of that section of the course, let me give you a bare bones outline here.
Log in as the user whose files you want to secure.
Create an encrypted disk image using Disk Copy at the top level of the user's home directory. When it asks for the disk image password, be sure that the "remember password" option is checked -- this saves the disk image's password on the user's default keychain.
Use ditto to copy over the following directories from the user's home folder onto the encrypted disk image:
~/Desktop ~/Documents ~/Library/Mail ~/Applicat ion Support/Addresses ~/.ssh
These are the important ones; you can copy over other items as well, but definitely don't do the entire ~/Library folder, and don't do the ~/Library/Keychains or ~/Library/Preferences folders.
Set the disk image to automount on login by dragging it into the Login Items preferences pane.
Use mv to shift the directories aside (e.g. mv ~/Documents ~/Documents.save) and set up symlinks onto the disk image (e.g. ln -s/Volumes/Secure/Documents ~/Documents).
Log out and log back in again. The disk image will be automounted at login, using the password stored on the default keychain which also unlocks on login. Everything should just work!:-D
Now for the housekeeping: delete the.save directories you created earlier, and be sure to turn off automatic login in the Accounts preferences pane.
Why do it this way instead of the way that Joshua Gitlin wrote up? First, you don't need admin access to a machine to make it work. You may not have admin access on a company machine, or as a sysadmin you may not want to give admin access to most of your users. Second, using Joshua's method, once the disk image is mounted it's open to anyone who has admin access on that machine, whether or not you are logged in at the console. By using an automounted image with the password stored on the keychain everything is secure until you actually log in, and everything is secured once you log out. Third, this way is a lot more convenient. If you make security too inconvenient, users will circumvent it. Instead of two logins, you only have to do one. Techincally unsophisticated users (secretaries, lawyers, vice-presidents, etc.) don't need to do anything different.
<BLATANT PLUG> Go to Apple Training and sign up for a course or two. They're well worth the money and help me keep my job.:-D </BLATANT PLUG>
--Paul psuh at apple dot com Curriculum Developer Techincal Training and Certification Apple Computer
Looking ahead to the Mac release, the place to announce it is on VersionTracker. All the Mac-heads look there for new and updated software. They have a Windows section too, but I can't say how useful it is.
Can Mac OS X and OS X server determine whether or not a user is an administrative or non-privileged user when it authenticates against an Active Directory?
Yes. It all has to do with the "admin" group. If the user is a member of that group, then he or she has admin privileges. If the user is not a member, he or she does not.
zerofoo, you're beating on the locknut with a hammer again:-)
Windows does AD replication because AD is a much heavier weight protocol than LDAP, or indeed most other directory services systems. As such, each W2K server is better off replicating information rather than accessing a central store.
However, LDAP is very light weight. Accessing a single central server for information does not add appreciably to network traffic, even for many machines and users. As a result, it makes no sense to have a copy of the DS database in each server and then worry about replicating changes in one to all of the others. In fact, the AD replication process is actually fairly complex, due to the need for distributed locking and conflict resolution. This is a lot of extra code that really isn't needed.
Most other DS architectures have provisions for replication as needed. For instance, Mac OS X's native NetInfo DS architecture has provisions for cloning the DS database for geographic dispersal (think wide-area networking), load balancing, and redundancy, including the ability to change a clone into a master if the master fails. It also has a multi-level DS architecture so that administrators of the top level domain can delegate authority to lower level administrators for particular sections of the network if need be.
Changes to the top-level domain using NetInfo Manager or Workgroup Manager can be done on any Mac OS X machine, connected to any server in the hierarchy. These changes are then pushed to the clone servers without the need for complex distributed record locking and conflict resolution.
While NetInfo can provide name resolution services to machines that it knows about, it really isn't meant for this and shouldn't be used for it. There are many BIND name server implementations, and any of them can be used interchangably with NetInfo. The DNS system as a whole has provisions for master and slave servers, and synchronizing changes from masters to slaves.
NetInfo doesn't try to handle DNS, really. DNS resolution has a whole different paradigm than directory services lookups. Instead, NetInfo reflects the Unix philosophy of one process doing what it does best, and letting other processes handle what they do best. Linux works the same way. Only on Windows do you get the One Humongous Beast That Does Everything And Guzzles Resources.
Slashdot Mirror
Note that I said "cost... with overhead". As a rule of thumb, you figure the true cost of an employee to be 2x what the employee is paid in salary, when you take into account equipment, social security payments, benefits, training, travel expenses, office space rental, etc. So a person who makes $50,000 a year (~$25/hr) has a total cost to the employer of $100,000 a year (~$50/hr).
--Paul
I've worked on some government contracts, and in my opinion a big part of the problem is in the GSA schedule rate structure that the Federal uses for contractors. It is much more profitable for a contractor on a government project to put many junior people on a project rather than a few senior people, for the same amount of revenue. For instance, a junior developer may cost a contractor $50/hr with overhead, but the contractor is able to bill the government for that junior developer at $150/hr., a spread of $100/hr. A senior developer may cost $100/hr with overhead, but can only be billed to the government at $175/hr, a spread of only $75. Furthermore, the contractor can bill more hours of junior time than senior time under a given budget cap, compounding the effects of the greater spread. Thus, the incentives for contractors are to use as many junior developers as possible on a project, to increase the profit margin.
Unfortunately, It's a rule of thumb in this industry that a few good programmers are a lot more productive than many unskilled ones. The result is that many government IT projects are shoddily built by well-meaning but inexperienced developers who are put in that position by a contracting structure that fails to recognize the realities of the IT industry. Contractors are just responding rationally to the incentives that are presented to them.
These numbers are examples -- in fact the situation may be even worse. Federal government contracts vary in their rate structures, and many are stingier than this. It may well be impossible to bring on a senior developer as a subcontractor because the maximum hourly rate that the government will pay on a project is lower than the cost of the senior developer.
A prime contractor that I worked with staffed a large WebObjects project for the Department of Defense with a dozen or so low-paid, fresh out of community college drones. Every six months -- when a project review was due -- they would bring us on board as subcontractors for six to eight weeks. In that time, two or three of us would take the code base from where it was four months ago and bring it close enough to the required progress to get the contract renewed, and then the prime contractor would say "goodbye" and toss us out. Four months or so would pass by, with their people making little meaningful progress, and we would get a panicked call for six or eight weeks of more work to get by the next project review. (Did I mention that the prime contractor didn't pay the bills for one set of work until they needed us for the next project review? It got so bad that at one point we had to treat them as though their credit rating was zero, and demanded that payment for each week's worth of work be deposited in an escrow account before we would continue.)
By the way, this rate structure is not unique to government IT projects. Other types of government projects display the same professional services rate structure. When I worked for a (then) Big Six accounting firm as an economist, most consulting projects for corporate clients were staffed with a ratio of one partner and two or three senior managers to six or eight associates. However, the Federal government group was staffed with a ratio of one partner and one senior manager to twenty or so associates. I talked to the senior manager, and he told me that (a) the associates in the government contracting group were paid much less than we were on the corporate side since they billed out at a lower rate, and (b) the only way they could make money was to use lots of cheap associates because senior people could only break even at best at government rates.
Ya know, it'd be nice to see a GSA person squirm over this sort of thing in front of Congress some time. Then again, Congress may be part of the problem, as they'd rather generate lots of jobs for constituents, instead of a few.
--Paul
AMEN! I distinctly regret that I don't have mod points right now. I have an ABD in Economics and years of work experience doing econometrics, and this analysis nails how the MTBF calculation is done exactly.
One quibble I have (more with the HD manufacturers, not crmartin) is that HD have mechanical components (spindle, actuator, etc.) that are subject to wear. As a result, MTBF calculations that are appropriate for solid state electronic equipment not subject to physical wear are likely inappropriate for HD's.
--Paul
Version control definitely belongs in the filesystem. Clearcase may have a lot of implementation uglies, but as a concept it clearly works. Filesystems manage files, and that should include managing file versions.
One place to look for (sort of) file system versioning support is Subversion, an Apache-licensed replacement for CVS. You can mount this via webdav_fs, and you get automatic versioning that works with just about any application, although right now you need to use a separate client to get access to older versions of the files. Still in alpha, but very stable and worth checking out.
--Paul
Unfortunately, Assimilator won't work for installing Mac OS X as there are hard linked files that Assimilator won't handle properly. Use a combination of Netboot and ASR, or Netboot and Mike Bombich's NetRestore.
--Paul
From your description and your web site, what you need is not "version control" or "source code management" or "configuration management" software (which is what cvs or subversion provide), but a "content management" system, which contains editorial workflow, publish/unpublish capability, probably the ability to generate static pages, be a web services provider, etc.
Try one of the following for size:
Tiki
phpWebSite
OpenDocMan
Your workflow requirements seem to be a lot more sophisticated compared to most sites, but one of these projects may serve as a starting point.
--Paul
Take a look at one guy's experiences with blocking rude bots and spiders. Mark is a buddy of mine and this got him pretty steamed.
--Paul
No idea. I'm not part of the FreeBSD team, and in fact I'm more of an OpenBSD user/sysadmin. Try asking on one of the FreeBSD lists.
--Paul
My understanding is that a journalled FS records every file block allocation and deallocation on the volume in a separate journal. This way, if an operation does not complete (say, due to a power failure), the disk can be restored to a known consistent state very easily. A consistent state is one where no blocks are allocated that should not be, and no blocks that are in use are listed as unallocated.
Softupdates does a partial re-ordering of operations so that all allocations happen before deallocations. Thus, in the event of a crash there can never be any blocks that are in use but marked as unallocated. The only possible inconsistency is that there may be blocks that are unused but marked as allocated. In the event of a crash, no fsck is performed as a part of the boot sequence, but a special background version of fsck is run to find any blocks that unused but marked as allocated and mark them as unallocated, which is a safe operation.
Comparing the two methods of operation, a journalling FS pays a speed penalty under normal operations, as it needs to do two writes to the volume for every write access from the application, one to write the journalling data and one to write the actual write. However, on a restart after a crash, the journal is just used to roll back the volume's allocations to a known good state and the OS continues on its merry way.
FFS with softupdates is faster under normal operations, as there is only one write to the volume for every write access from the application. However, in case of a crash there is the potential for a large quantity of disk blocks that will need to be scavenged, thus making the volume look like it has less free space than it actually has, plus the background fsck needs to run and fix up the allocations.
Read the Ganger and Patt and McKusick papers linked to in my original post for more details.
--Paul
JFS, other journalled file systems, and Softupdates have the same goal -- keeping file metadata structures consistent on the disk. JFS does not attempt to maintain file data integrity in the event of a crash -- that is the job of a DBMS. Go and read the web page on JFS from IBM that is linked to in the original posting.
Granted, journalled FS's and softupdates go about things in different ways. Softupdates trades off potentially increased disk space usage and higher disk and CPU activity after a crash (performing the background, reduced set of checks in fsck) against a smaller relative performance penalty vs. a non-journalled FS in normal usage as compared to a journalled file system.
My own $0.02 is that this is a nice scratch-the-itch, check-the-box-for-PHB's addition, but for most normal usage softupdates is a better choice. See the papers by Ganger and Patt and McKusick for more details. (Links copied from the OpenBSD FAQ pages.)
--Paul
This is still not adequate -- and is (in some ways) worse than nothing. Having managed a lab of student computers back when I was a grad student, often times people will simply sit down at an otherwise unused computer and start typing in URL's. If the attacker installs the software (not requiring a reboot) on a machine and walks away, the next user and any other users who use it without a reboot will still be vulnerable. The keystrokes can be recorded by sending them to an SMTP relay or open FTP server.
This is worse than nothing because if the machine is rebooted then you have just lost any chance at doing forensics on the attack.
There are far better solutions available. First, do NOT allow user software installations -- this should be a part of the TOS for such a lab. This in turn allows you to lock down the machines very tightly. Downloads can still be allowed to a user's network account or floppy or zip disk or USB keychain device.
In a managed environment such as a university, require students to log in to computers with campus-wide accounts. Win2k and XP, Mac OS X, and most unices support Kerberos logins, which are becoming widespread on campuses. This gives students their own home dirs automatically, with saved prefs, etc. It also allows much easier forensics on attacks as well. If you want to allow public access, post a public login to an account that has zero privileges on the wall of the lab.
By going this route, you can then use netbooted machines without internal hard disks, vastly simplifying maintenance and system administration. Netbooting is not always easy to set up, but the payoff is well worth it in such lab environments.
--Paul
Apple's version of OpenLDAP uses NetInfo as its backing store -- the apple.schema file merely exports the contents. Go to a Mac OS X Server machine and look at the values it puts into NetInfo. This will give you examples of what you need to put into the corresponding LDAP server entries on your Linux server.
Probably easier is to just use the LDAP values you already have in the RFC 2307 schema for your Linux machines, and set the Mac OS X machines to use the RFC 2307 schema by using the Directory Access application.
--Paul
I'm a curriculum developer for Apple's Technical Training and Certification department, and I also act as the backup sysadmin for our Reston, VA training center. All of our courses are hands-on using serious equipment, with an iBook laptop and a G4 tower at each student station, along with a G4 tower for the instructor and possibly also (depending on the class) an XServe rackmount, a Windows 2000 Server, and Solaris servers, all networked together.
The classes run three to five days, each day covering on average three chapters. Each chapter consists of an instructor presentation for about 30 minutes, followed by a student exercise that runs between an hour to two hours. As you can see from the time involved, our approach definitely emphasizes the hands-on aspects.
I can tell you as one of the people who both writes and teaches Apple's courses, most people will zone out if they have to listen to the instructor for more than 30 minutes. At the technical training level, I can't imagine sitting through a straight lecture class for a whole day without a hands-on piece, and really retaining very much of the content.
--Paul
Paul Suh
Curriculum Developer
Technical Training and Certification
Apple Computer
psuh at apple dot com
One thing that all of the various "quality assurance" regimes miss entirely is the value of being able to make mistakes. Risk-averse managers love this "zero defects" kind of environment, because they like the predictability. However, for the organization in a rapidly changing environment, such predictability is often deadly. Achieving the goals takes too long, and by the time you have perfected a process it's obsolete. Customers have moved beyond what you are doing and demand something else. Your perfect buggy whip is no longer useful in an age of automobiles.
Six Sigma and the like were developed in a manufacturing environment, where the same processes are used for years, and there is time to get it perfect. In the IT industry, two or three years yields a radically different environment. People need the room to take risks in order to deal with such a dynamic environment. The corollary is that in taking risks, sometimes you roll snake eyes and crap out. People make mistakes and if you focus only on the down side, you miss out on the greatly increased upside that comes from taking those risks.
Six Sigma in the IT department sounds like a loser. In IT, you want a management style that is looser and and more free-flowing, able to shift quickly, and not stuck on not making mistakes. (Perhaps the biggest mistake to learn from would be to try to apply Six Sigma to your department!)
--Paul
One of the best things that you can get out of Fowler and Sadalage's article is some idea of the benefits that an object persistence/database abstraction layer can give you. I work with WebObjects, which comes with the Enterprise Objects Framework, a powerful, mature object persistence layer. Think of it as entity Enterprise Java Beans, except that it's a lot lighter in weight at runtime since everything happens in the same address space, along with about 5 years maturity over entity EJB's and very powerful relationship management.
This gives you the ability to let most of your developers works solely with the object model, and encapsulates things like calculating an age from a birth date and today's date or a full name from first name and last name without polluting the database with miscellanea. Only one or two or a specified small team of people need to be concerned with the design of the database and writing SQL. All of the other developers can just use the Enterprise Objects and not worry about it.
However, this brings me to another point -- all of the successful WebObjects projects that I have seen share one thing in common: a highly skilled architect who has a solid understanding of not only the development process but also how databases work. A good developer teamed with a good DBA is no substitute for one master artiste in this case, as the master can know how to create an object design that meshes precisely with the database to optimize performance and ease of development, as well as making it relatively easy to create the UI.
In fact, a sign of a well-run WebObjects project is that for the first week or two, most of the developers are sitting on their hands or taking long lunches or reading Slashdot. During this time, however, the senior person or two is taking the time to get the underlying data object model right. Only when that is solid does the manager unleash the rest of the troops.
--Paul
Another factor involved in using NFS with Windows clients is the security model involved. To expand on Jeremy Allison's excellent comment, the NFS security model relies totally on the UID at the client. Since there is no native concept of a UID in Windows (plus the fact that the Win9x branch doesn't have good user privileges separation in any case), this means that you need a separate login from the Windows PC to the NFS server, using a system known as PC-NFS originally created by Sun. There is an open source pcnfsd daemon that will handle this at the server end, but the client piece is not free, and the whole thing is a PITA to set up, and is one more thing that can go wrong on a fragile Windows client system. Much better to use Samba on the server and not have to rely on yet another skanky layer. (Been there, done that, have the therapist bills to prove it :-P)
FWIW, the Mac OS up through version 9.2 has pretty much the same set of issues. Mac OS X, being Unix-based, has NFS server and client support natively.
--Paul
On Mac OS X, the password is stored as a standard Unix-style crypt hash with eight significant characters. It's no more or less secure than most other Unix-style systems that use this system -- this is reasonably secure if you use a solid password. Upper and lower case, numbers, punctuation, etc. I'd personally prefer that it take into account more significant characters, but "this will be covered in a later release". Using the OpenLDAP-based password server from Mac OS X Server gives you 255 significant characters via SASL, but this isn't usable in the case where you want encrypted disk images the most, on a laptop away from any network.
A pretty good way to make a difficult to crack but easy to remember password is to string together two words with some punctuation in between. E.g., my old (now defunct, so don't bother trying it) Compuserve account password, "knife:other". On Mac OS X, this reduces to "knife:ot" which is easy to remember but hashes to something pretty difficult to crack by brute force.
--Paul
Curriculum Developer
Technical Training and Certification
Apple Computer
One more thing -- people have been commenting/asking about the speed of access. The algorithm for AES-128 on MOSX 10.2 has been heavily optimized. There is basically little or no additional overhead when using an encrypted disk image vs. an unencrypted disk image.
--Paul
The underlying AES-128 encryption is part of the Darwin distro. Look in the Darwin sources under:
src/Security/AppleCSP/AES/
This still doesn't really address the whole question -- if there's some back door somewhere higher up the stack in the disk mounting code, you won't find it here, but it's part of the solution. Validate the AES-128 code, then treat the encrypted disk image as a black box (using a simple password, without loss of generality) and see if you can decrypt the image by hand or using a util that you write yourself.
OK, I work for Apple so you really can't fully trust me on this, but I certainly don't know of any intentional back doors in this code.
--Paul
psuh at apple dot com
Curriculum Developer
Technical Training and Certification
Apple Computer
- Log in as the user whose files you want to secure.
- Create an encrypted disk image using Disk Copy at the top level of the user's home directory. When it asks for the disk image password, be sure that the "remember password" option is checked -- this saves the disk image's password on the user's default keychain.
- Use ditto to copy over the following directories from the user's home folder onto the encrypted disk image:These are the important ones; you can copy over other items as well, but definitely don't do the entire ~/Library folder, and don't do the ~/Library/Keychains or ~/Library/Preferences folders.
- Set the disk image to automount on login by dragging it into the Login Items preferences pane.
- Use mv to shift the directories aside (e.g. mv ~/Documents ~/Documents.save) and set up symlinks onto the disk image (e.g. ln -s
/Volumes/Secure/Documents ~/Documents). - Log out and log back in again. The disk image will be automounted at login, using the password stored on the default keychain which also unlocks on login. Everything should just work!
:-D - Now for the housekeeping: delete the
.save directories you created earlier, and be sure to turn off automatic login in the Accounts preferences pane.
Why do it this way instead of the way that Joshua Gitlin wrote up? First, you don't need admin access to a machine to make it work. You may not have admin access on a company machine, or as a sysadmin you may not want to give admin access to most of your users.Second, using Joshua's method, once the disk image is mounted it's open to anyone who has admin access on that machine, whether or not you are logged in at the console. By using an automounted image with the password stored on the keychain everything is secure until you actually log in, and everything is secured once you log out.
Third, this way is a lot more convenient. If you make security too inconvenient, users will circumvent it. Instead of two logins, you only have to do one. Techincally unsophisticated users (secretaries, lawyers, vice-presidents, etc.) don't need to do anything different.
<BLATANT PLUG>
Go to Apple Training and sign up for a course or two. They're well worth the money and help me keep my job.
</BLATANT PLUG>
--Paul
psuh at apple dot com
Curriculum Developer
Techincal Training and Certification
Apple Computer
Looking ahead to the Mac release, the place to announce it is on VersionTracker. All the Mac-heads look there for new and updated software. They have a Windows section too, but I can't say how useful it is.
--Paul
Let's take this offline -- and let actually type my e-mail address this time! Paul Suh psuh at apple dot com
--Paul
Let's take this off line -- Paul Suh
--Paul
Can Mac OS X and OS X server determine whether or not a user is an administrative or non-privileged user when it authenticates against an Active Directory?
Yes. It all has to do with the "admin" group. If the user is a member of that group, then he or she has admin privileges. If the user is not a member, he or she does not.
--Paul
zerofoo, you're beating on the locknut with a hammer again :-)
Windows does AD replication because AD is a much heavier weight protocol than LDAP, or indeed most other directory services systems. As such, each W2K server is better off replicating information rather than accessing a central store.
However, LDAP is very light weight. Accessing a single central server for information does not add appreciably to network traffic, even for many machines and users. As a result, it makes no sense to have a copy of the DS database in each server and then worry about replicating changes in one to all of the others. In fact, the AD replication process is actually fairly complex, due to the need for distributed locking and conflict resolution. This is a lot of extra code that really isn't needed.
Most other DS architectures have provisions for replication as needed. For instance, Mac OS X's native NetInfo DS architecture has provisions for cloning the DS database for geographic dispersal (think wide-area networking), load balancing, and redundancy, including the ability to change a clone into a master if the master fails. It also has a multi-level DS architecture so that administrators of the top level domain can delegate authority to lower level administrators for particular sections of the network if need be.
Changes to the top-level domain using NetInfo Manager or Workgroup Manager can be done on any Mac OS X machine, connected to any server in the hierarchy. These changes are then pushed to the clone servers without the need for complex distributed record locking and conflict resolution.
While NetInfo can provide name resolution services to machines that it knows about, it really isn't meant for this and shouldn't be used for it. There are many BIND name server implementations, and any of them can be used interchangably with NetInfo. The DNS system as a whole has provisions for master and slave servers, and synchronizing changes from masters to slaves.
NetInfo doesn't try to handle DNS, really. DNS resolution has a whole different paradigm than directory services lookups. Instead, NetInfo reflects the Unix philosophy of one process doing what it does best, and letting other processes handle what they do best. Linux works the same way. Only on Windows do you get the One Humongous Beast That Does Everything And Guzzles Resources.
--Paul