Re: A small suggestion to improve ls

[Ray Dillinger]

On 12/27/2014 03:44 AM, Pádraig Brady wrote:

> We couldn't change the default output format of ls -l at this stage.
> Note the symbolic modes could be one of these at least [rwxXst].
> Also note that chmod can accept these symbolic modes. chmod a+x etc.
> https://www.gnu.org/software/coreutils/manual/html_node/Symbolic-Modes.html
> Personally I rarely use numeric modes.
> 
> Also note that tools like `find` can be leveraged to display symbolic modes:
>   find -maxdepth 1 -printf '%m ' -ls
> 
> This is something we might consider adding to ls if we
> ever support a --format option, which would give more
> flexibility on fields to output.

This message is somewhat offtopic W/R/T maintaining coreutils
infrastructure, but is rather about a possible future direction
for coreutils and system design.  Any pointers about what would
be a better place and/or method to bring this up will be
appreciated.

The Unix permissions convention of root:group:user is IMO no
longer really adequate for the security issues we're facing at
this point, and should probably be replaced with a convention
of root:usergroup:user:exegroup:executable.

The evolution I propose changes the structure of file permissions
to keep track of a program/program group having privileges over
that file, and gives the users access to tools for administering
the privileges of programs/program groups running under their
own login.

Regulating privs by root:group:user was the right answer when
the only thing we really needed to protect was the system
integrity, and the question was simply "whom can we trust?"

But that's no longer the case.  Users (not just root) now value
system integrity mainly (or only) because system integrity is
necessary to protect assets far more valuable to them than the
system itself.

But, while necessary, it is not sufficient. The primary threat
to those assets comes not from other users, but from software
running under their own account, with their own privileges, that
does things using their privileges which they did not anticipate
and would not approve of that software doing.

The trust issue between individual users' assets and the
privileges given the executables that they run is now as severe
in terms of preventing losses to individual users, as the trust
issue between system integrity and the privileges accorded
individual users.

Accordingly, I think a future evolution of Unix probably ought
to have users able to control delegation of their privileges to
executables running under their login, in exactly the same way
that root controls the delegation of privileges to user accounts.

So, a user who has just downloaded "SOOPERGAME.SWF" may have
no problem with it having privileges to read and write in its
own directory in his home folder, but has no real reason to
trust its authors and absolutely would not give it the
'executable group membership' or however this works, that it
would need to read/write in his customer database, mail spool,
or bitcoin wallet.

Which would mean that securing operations should check the
privileges of both user (to be sure the user has the authority
from root) and the executable (to be sure that the executable
has the authority from the user) before allowing an operation.

                                Bear

signature.asc
Description: OpenPGP digital signature