Custom Settings have nothing to do with sharing. Making your classes without sharing might cause your classes to disregard other permissions, but not custom settings.
Custom settings have two permissions:
Everyone can always read a public custom setting (and apex code can). If the setting is a protected and it is within a managed package, then no one can read the setting (but Apex code running within the namespace can).
Only those with 'customize application' permission can modify a public custom setting. No one can modify a protected custom setting (but apex code running in the namespace can).
In other words, for custom settings, apex code within the same namespace will always be able to access them for both read and write. It doesn't matter if the code is with or without sharing, as sharing has nothing to do with custom settings.
However, custom settings have their own CRUD/FLS settings -- you can query each custom setting by its api name and get the result to an isUpdateable call, for example. And the results of these calls are respected in the default visualforce components that respect CRUD/FLS (e.g. inputField and outputField versus inputText and outputText). Therefore you cannot use these (*field) components in order to update custom settings unless the user has customize application permission.
Please don't try to fix known visualforce component behavior by introducing a bunch of without sharing classes in your controller. One is not a solution for the other, but rather by burying your field data within another class, you are forced to not use the visualforce *field components, and this is what makes it appear as if multiple 'without sharing' classes are the answer to your problem.