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(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
