Claudio Freire wrote:

Excuse the top posting, on a cell here and it's difficult to bottom post.

Most gui email programs make it easier to put the most recent stuff at the top -- organizing a timeline from most-recent - older as you go down. Professions that need things organized chronologically tend to use this (medical, legal). Only those who think every detail is important, all the time, for everyone, force bottom posting.

I don't think patching the bare minimum is a good idea in this case... the more restricting the rules are the less likely the issue remains exploitable in yet unknown ways.

Get rid of root entirely -- no exploits... Maybe cut the power as well. Let's take no halfway measures, eh? Um... you are changing system wide security policy. It seems like doing the minimum necessary to disable your exploit(s), is the best idea since every little bit that you change will cause more incompatibility for some program(s) somewhere -- not to mention this breaks posix rules, linux DACL rules, normal unix access restrictions, to name a few.

But maybe restrictions can be relaxed a bit to allow for your use case, if it is common enough. Can you show an application that is broken by current rules and that cannot be fixed without changes to the rules?

Can you show that your changes break no existing applications? You are proposing the changes but there's been no proof that any compatibility testing was done other than "ubuntu did it". Ubuntu, of course, is known to cater to the technically sophisticated users... who would be likely to use a variety of security scheme, right? Noooop. Ubuntu was designed for those coming from windows -- designed to take away decision points and make things simpler -- which I AGREE with -- but not at the expense of flexibility. I know the features can be turned off, BUT, Some vendors are designing new distro features based on the reduced functionality offered by the increased restrictions -- like putting everything on 1 partition. That used to be considered "bad system administration" and a bad practice for security, maintenance and reliability. It still is, but convenience is trumping everything else.

What you mentioned in the op seems a rather niche use you scripted yourself and unlikely to be common.

Now here's where you are way off, as well as trying to create a self-fulfilling trap. ANY time you script something, it means you have a custom solution -- that by definition is a 'niche use'. If it could be done without a script, it would be a general use case implemented as a feature. Well guess what. There is no script involved. It's a general use case: "cp -al". I've been on many projects where one copy of the source was the pristine, read-only source, and people used links to create a low-space usage copy. This allowed them to create files as 'new files' where they made changes -- everything else was a read-only link enforced by it being a different UID. It may not be a common use case for home users, but for anyone who does development, it's among the simplest and easiest way to create a local "copy" that you can make changes to while keeping the overall disk cost low where you are re-using the original code.

For those cases specifically, there's a sysctl to disable hardlink protection.

Actually, having the hardlink protections disabled are the default case. Opensuse turned them on in /usr/etc/sysctl.conf. Why wouldn't less overwhelming patch work? Specifically w/r/t prot.hardlinks: 1) cannot hard link to a setXID file unless you could create it yourself. 2) cannot link to/from a file in a world-writable sticky-directory. 3) Root privileges will not override sticky bit rules in the case of opening w/write. I.e. if a file already exists in temp owned by another user, root cannot open the file for write in 1 step. They must first either move or remove the sticky file. The latter step (3) makes the system safer than your proposed solution -- since as it is now, root can overwrite (accidently) any user created tmp file in /tmp, possibly destroying valuable work. ========================= Conversely -- specific criticisms of the new implementation: users can hardlink only to writable, regular files. The reasoning is to prevent race conditions and users writing into files expected to be used by root; BUT -- the new restrictions disable hardlinking to other file system objects -- in ALL CASES except where their UID=the object's UID. This disables Group control as well as control by access lists. A great deal of work has gone into making access lists viable -- and work went into making group access viable as well -- yet this disables both of those access methods for controlling hardlinking to writable objects (other than regular files). The irony, is that you can't have setXid objects other than *files* -- and the TOU exploits don't apply, EXCEPT to files... (i.e. they don't apply to hardlinking to symlinks, as you can't rewrite the symlink, they don't apply to other objects either -- named pipes? sockets? semaphores? None of those suffer from the TOU exploits -- yet they were all disabled unilaterally -- and don't even work when you have write access to those objects. ???? That doesn't make sense. If the idea was to protect against TOU problems, why disable linkability to other objects (besides files)?

If you can show a more widespread use case that is similarly affected, that will encourage kernel developers to come up with less restrictive rules

The onus should be on those proposing the wide-ranging and incompatible new rules to prove why they are needed to the extent implemented. If no proof is needed, then just eliminate root, or pull the plug -- the former is practical with FLASK/SeLinux. But the problem is the bigger the change, the more things you break -- which is why I argue for the minimal change necessary. If you want a maximal solution, SELinux is already available. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org