Re: debmake suid programs
In article <Pine.LNX.3.95.961107064046.3406Bfirstname.lastname@example.org> you wrote:
: I think most of the discussion regarding the debmake wrappers is
: missing the point.
I don't think this is the case. I'm a debmake user, and I think it
represents some really great work! Hoever, I disagree with your assessment
of the priveledge situation. I'll try to explain why.
: 1. In the past it was necessary to become superuser to build a package
: due to the nature of the dpkg tools.
A good way to phrase this would be that "it is necessary to acquire additional
priveledges in order to build a package". This has always been true, and
When discussion raged on this topic many months ago, Ian Jackson pointed out
that anyone installing a package would need to be priveledged, and since we
expect maintainers to test their packages before releasing them, this did not
represent a unique expectation.
It is *not* necessary either to maintain or install a package that a user be
given full superuser access to a system. Tools like sudo allow much finer
grained control over priveledge.
: 3. The permanent need to type superuser password and to issue superuser
: commands is something that is really bothering me. I want the time
: that I spend at the superuser prompt be as minimal as possible. I know
: I can make bad mistakes at that point.
Have you installed and tried sudo? Your comments suggest to me that you
have not. I think the way it handles passwording without requiring you to
run all commands in a superuser shell is quite reasonable.
: 4. Since every person needing to build a package already MUST have full
: access to superuser priviledges it is reasonable to put those users
: into a group (debmake uses root) and structure/simplyfy the access to
: avoid "accidents" by issuing commands that might have unintended
: 5. The wrappers are only accessible to those persons with group membership
: in root and they only execute commands necessary for building a package
: with due considerations of all the percularities of the dpkg tools
: minimizing the superuser environment created.
I don't think you've thought about this enough yet.
When you use a tool like sudo which requires a user to provide their own
password to acquire additional priveleges that have been granted to them by
a system administrator, it is a fundamentally more secure approach than
assuming that just because a shell is logged in as a particular user that it
should be able to perform priveledged operations.
Sudo allows an audit trail, your approach does not. Sudo protects against
walk-up attacks from an unattended terminal, your approach does not. Sudo
reduces the paths of risk exposure to one config file and one well-reviewed
suid executable, your approach increases the number of executables that are
potentially vulnerable to attack. Sudo keeps information about which users
have been given which extra priveleges for which commands in a root-read-only
file, your approach puts information about which users have been granted
extra priveledges into a world-readable file (the group file) so that
attackers know which user accounts to focus their efforts on.
There are probably other issues, these are the ones that fly to the front of
my mind instantly...
: 6. The build, debclean and debpkg wrappers help to simplify things that
: a develop does again and again and again. It is a great help to develop
: packages and thus a important part of debmake.
I completely agree that debmake is cool, and that the way you've coded all
the normal things folks have to do is a real labor saver, and probably will
help to reduce the number of "silly errors" that package maintainers make.
This is true even without trying to add priveledge management.
: I would be glad to get informed responses to this message and get
: recommendations to improve things but please study the issue first.
Leave the priveledge management out of the debmake toolset. There's nothing
wrong with having a package maintainer type 'sudo <command>' instead of
'<command>', and it's fundamentally more secure while being only trivially
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com