On Wed, 2004-03-31 at 15:47, Gary L Greene Jr wrote:
> On Saturday 27 March 2004 06:05 pm, Robert Marcano wrote:
...
> >
> > I am sure that the filesystem can be arranged in order to make it more
> > easy to use to the desktop user, Your ideas of a shared directory is
> > nice, but letting the user "Easily install software without escalating
> > their privileges" is something that I don't like. The only way that I
> > like a shared directory is if it is mounted from a filesystem with the
> > "noexec" flag.
> >
> > I think that the software installation can be made easy with the help of
> > a better "Add/Remove Programs", and the security aspect could be
> > enhanced with the help of a SELinux policy for this program(s) (I am not
> > an expert in SELinux, so I could be wrong)
>
> The problem with adding software installation only through the root
> directories is that you still need to have root privileges to install a
> program. This proposal is to allow people to install programs, but not as
> root. This adds no new abilities. None. It just makes it easier. Already,
> people can install any program in their home directory, it is just a lot of
> hassle. This is just a way to organize it.
For what I have learned of SELinux, I think that it could be used to
give special privileges to certain processes (for example the Add/Remove
programs of the distribution) to do whatever it wants on the system by
defining the appropriate SELinux policy. For example the policy can
allow to a program to install new files on /usr/{bin,lib,share,...} or
update the files of a previously installed version of the application
without asking any root credentials to some users of the system, or all
if wanted. This is the more secure way I think it can be done
... continues ...
> The purpose is for home installation. Here is a sample setup: I have a
> computer used by four people. I own it and want to run it. I want to allow
> the other people to install programs without asking me. This lets them do
> installations without needing to be root.
>
> This doesn't pose a security issue because the programs installed thus do not
> have higher privileges than those of the user that installed them.
>
> This will in fact improve security on many home installations because users
> will not need to be constantly entering their root password and will be less
> likely to just turn the root password off.
Leaving to another time my differences with your proposal ;-), I think
that you must add to your document information about the search order of
the PATH, LD_LIBRARY_PATH, etc. You can include for example that for
security reasons it is mandatory that the system libraries and
executables need to be loaded before any user installed ones; or the
other way: in order to allow the upgrade of system installed
applications the search path is reversed to allow that. What the
standard will recommend? changes to LD implementation in order to allow
the load of the user installed shared libraries. or the usage of the
environment variable LD_LIBRARY_PATH
Do you know that a lot of user oriented applications store files on
/usr/share (and others)?, and that directory is defined at compile time
(nearly on every application that uses it), so you will need to build
the application specially for the directory you are deploying, and on
"home installations" the users will not build their custom versions
> Also, note that this is not intended for server installs, as is stated in the
> proposal.
>
> Thank you for the feedback.
Hope this helps
--
Robert Marcano
