On Wed, 2004-04-07 at 19:44, Michael Jennings wrote: > On Wednesday, 07 April 2004, at 19:01:26 (-0700), > Michael A. Peters wrote: > > > Several administrator accounts (both Windows and OS X are this way) > > wheel group > multiple UID 0 accounts > sudo/slide sudo imho is evil, it takes very careful administration - absolutely nothing that can possibly spawn a shell. > > How, exactly, would a non-privileged user be able to write to the RPM > database files? That's why there is a second rpm database in /software. The database for user installed apps is writable by the wheel/admin/staff/whatever group. The only thing to stop your user from installing rpm's on your current system is that only root can write to that file (and permission to write in the directories where the files go) But if you have a relocatable package, and you tell it to install in your home directory using an rpm database in your home directory, you can do that right now. > And how would you keep the provision of these write > permissions from allowing corruption or other abuse of the RPM DB? That's why the /software rpm database is separate from the system rpm database. unmount /software and you have a system just like you have now but with no third party software. > > > This is why not everyone can install. Only trusted users - those in > > the group with write access to /software (which could be nobody if > > the root admin so chooses) > > What about software that requires special privileges? How are you > going to authenticate packages? or verify that a package comes from a > trusted source? I wouldn't trust anyone to install software with whom > I would not also trust root, because in the end they're the same damn > thing. Not really, no. the %post and %pre scripts will only run with the privileges of the person installing. In fact, this actually is SAFER than the current method. 1) buggy %pre and %post scripts won't be run as root 2) you won't need to be root to update software - I don't like the fact that both yum and up2date connect to the internet from a root shell 3) 3rd party applications are kept completely separate from the OS Vendor applications - so root can completely avoid them from being in its path 4) If an admin's account is compromised who doesn't have root, you don't have to worry about root compromise from a keystroke sniffer. mke2fs -j /dev/hd5 and any rpm's that johny installed when he hacked his teachers account are gone - but the operating system itself is fine. > > Windows has the problems it has because of its inferior security > model. Without that, there wouldn't be a slew of add-on products > schools use to keep students from adding www.penthouse.com to the > Active Desktop. Your approach strikes me as an attempt to address the > problem of end-user ignorance by tolerating it rather than eliminating > it. I think you underestimate the mischief of youth, or the blissful > ignorance of the educator, or both. Mischief youth can't get root if teacher doesn't have root. That means certain types of nmap scans can't be done even if they install nmap using teachers account. That means shadow can't be grabbed. Teacher doesn't have root, he only has authorization to write to /software - he can't meddle with the operating system vendor software, and potentially SELinux could be used to limit his activity in /software to only being allowed to install/deinstall via rpm. -- Cheap Linux CD's - http://mpeters.us/linux/ _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
