>> not a good idea. remove all special permissions from all >> files, and use sudo. guy could add a hook to his scripts >> on master, and reject all packages with suid/sgid >> permissions. it's a very easy thing. > >Not really. Administrators may decide not to rely on the >security of sudo, but on a few well-defined programs which >can be run suid root (things like /bin/passwd). There are >some places where perm & 07000 != 0 is needed or ok.
lets say : no package may have files with perl & 0700 != 0, becuase then an administrator setup a local security policy. but a package (such as passwd) may use suidmanager, to vote for a file to be suid root, or whatever. btw: as long term solution dpkg should integrate suidmanager. the reason is : if i want to modify the permissions of files not in the suidregistry, the ahcnge might get (temporary ?) lost during the upgrade to a new version. >> i agree. but /etc/suid.conf is fine, why an additional list ? > >The /etc/suid.conf has the local system administrator's >and the package maintainer's view of things. The >clearance list contains a different view which is based on >the clearance procedure, and recent bug reports. Think of >it as a way to distribute security knowledge to users. Packages without clearence should be removed from debian, or installed in a secure way, with README.debia or Security.note listing the details (maybe how to activate it). an additional source for informat is always ok, but the primary information should be in the packages, and they always must have a secure setup. >Think of an environment with lots of packets, where the >administrator decides to update some of them, including >the clearance list. He will then get warnings about >security problems on his system which may come from >recentyl discovered breaches, or from configuration >errors. there is one problem in debian : if you update your list of available packages, you only see "ah, a new version is available". you don't see whether it's a securiy fix, or fixing a typo, or a rather experimental trial+failure version. this information should be in a new package "security-advisor" ? i agree that this will solve the problem, but its a quick hack rather than a long term solution. but for now it's ok. oh, and please don't forget the devices, and other files. not only binaries are a security thread. if you have a local debian mirror, do a dpkg-deb -c of all files. you will find lots of files : - not owned by root or - not group root or - not mode 755 (dirs) 644 (files) 755 (files in */s?bin) many automatic services operate under their own user id (mail,news,lists,...) and such packages should follow the golden rule, too : if it's not absolutely necessary for a file/dir/link to have different owner/group/permission than root/roto rwXrXrX, don't do it. my last check found several strange things, so i wrote emails. don't know what happend. andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
