[Samba] NFSv4 acls inheritance flags

[Linda W]

Jeremy Allison wrote:
> I don't think ADS is ever going to happen, at
> least on Linux.
>
> Talk to Ted Tso about watching the Windows
> "Process Manager" running "myfile.txt" as
> a process (with a hidden stream .exe inside
> it) for background on why he thinks this
> is a *terrible* idea (Ted CC:ed on this one :-).
>
>   

That would be called burying one's head in the sand.  I vaguely remember
trying to explain an asymmetric security problem I'd found in the
capability code several years back and was given the brush off for
supposedly not knowing what I was talking about (not that there are many
times that I don't, mind you, but who's perfect? ;-)).  It was less than
a month later that cap's in the kernel were turned into a day-0 exploit
and were disabled in the kernel for the some number of years thereafter.

 From everything I've read ADS on windows (7 or before, dunno if things
have changed on 8)...they have similar security  "issues" to XFS extended
attrs.  Extended attrs are limited in size to something like 64K, but
that's more than enough to bootstrap something else.

Note: I understand that one *used* to be able to execute alternate data 
forks
directly in Windows 2000, but in Windows 7, people attempting to use the
same "feature", get a "not found" message -- the ADS can be "edited" or
opened with a text editor, but not executed directly.

Now someone can write a loader that opens "extended attributes" on
a linux system that loads them into memory to execute them (as one  could
on windows) but in current versions of windows, you can no more execute
a ADS, than you can a jpg (which is possible if it is bogus jpg or w/a
corrupt software reader, but then, all bets are off).

I.e. If you have your text files associated with a 'hacked' version of
some editor, or jpg-display util, it could read and execute the alternate
data forks.  instead of hand-crafted jpg or txt files. 

But this could happen on linux as well... There's a heavy emphasis on
making sure everything uses shared libraries, so fixes/patches .... and
shims... can be added later in the field.  But if your shim is an
extended-attr binary-loader, not much the OS can do about it -- i.e.
that's all user-space.  So your XYZ desktop has auto-associations to run
when you click on something... throw in a shim lib that looks for
extended attrs on a file... load and execute...

How is this different than the windows scenario?

At least windows as mandatory sensitivity levels built-in by default  and
you could might be able to recover a corrupt machine if the sensitivity
levels have been maintained and kept the user "editors" out of the
"system-integrity" level, on linux, what would maintain integrity w/o
running a completely different security model like.  MS has had the
ability to disable execution of all files except those signed by MS since
Windows 2000.  So someone sees something executing a trojan on windows --
windows systems are more likely to be used by computer illiterati than
nearly any other platform -- so it is more likely to be configured
wrongly if at all for any security hardening.

Windows security flaws are not usually at the kernel level -- but in
Win32 & equiv user routines.  But with the 'misc' binary option turned
on, you would seem to have close to the tools to execute trojans of the
sort that are normally limited to windows.

I.e. can someone explain how windows (and MacOS) are less secure for
having alternate Data forks (which Windows uses to record where files
originate from, (i.e. 'internet'), among other things, vs. linux having
no reliable** alt-forks. (**- meaning "it's just there").

BTW, just because I offer seemingly positive view on some features
doesn't mean I necessarily 'like' them.  Just being aware of what they
can and cannot do.

Linux is getting more "click+install" interfaces as time goes on,
I wouldn't think it is any safer in that regard than Windows (not that
either one can't be locked down so much as to be near unusable).

Linux is headed toward being able to be "locked down" out of the box
and only running secure code w/the Intel trusted-boot and such.  People
forget, it's MS that's been pushing that in windows -- very s.l.o.w.l.y, 
after
the public had a cow when it was call Palladium.  But it's still headed
that direction (for both win and lin).