– Not everyone can play
Although great on paper, read-only setup is primarily a Linux game.
– Patching becomes a chore
In order to patch a system, the read-only FS needs to be re-mounted in writeable mode. If the media is non-writable, such media needs to be replaced. As long as systems are left unpatched, no user information is secure and such compromised end nodes can be used to stage further attacks.
– Interoperability will suffer
Programs often keep vital configuration and operational data close by, inability to write such data might lead to numerous programs behaving abnormally, leading to potential system instability.
– Nothing is written in stone
Using a writeable medium mounted in read-only mode does not really reduce potential for vulnerability, as such volume can be re-mounted in writeable mode, so any changes can be saved permanently.
– Logs might be a problem
Given that the core system FS is read-only, it will be necessary to make sure that all logs are reviewed and re-linked to a writeable system. Quite often one can find logs outside the traditional /var/log directory.
– Adding new programs will get tricky
Not only patching existing applications will be difficult, getting anything new onto such read-only system will be problematic. If one needs to deploy a new application, the deployment will require the FS to get re-mounted, or completely replaced if it is represented by hardware that is not writeable.
– “Can’t touch this” MC Hammer style is annoying to end users
If a user does not have the rights to write to a specific location, or to access it, the OS notifies such user in a conventional way. If, however, a user tries to save something to a location s/he has access to, but the action fails due to the read-only nature of the underlying filesystem, the user will most likely perceive such behavior as system error and will definitely get annoyed. The behavior is not expected, so users will be confused, start to complain and call support.