Re: How Debian Linux could be made more secure
Richard Braakman <[EMAIL PROTECTED]> wrote: > Lintian would have to parse that in order to get a full list, and it > doesn't do that (yet). Another possibility would be to run a test install on some machine, with strace examining the calls used during the installation. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How Debian Linux could be made more secure
>> 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]
Re: How Debian Linux could be made more secure
On Wed, Apr 29, 1998 at 11:29:20AM +0200, Andreas Jellinghaus wrote: > a) every package should use suidmanager if it needs a 1000 2000 or 4000 bit. > b) every package should document why it uses this special permission in > /usr/doc//Security.Note (or README.Debian ?). Make it an extra file. > c) security should be more important than functionality or featurism. YES. > >- The Debian Installer should check for every package, if > > all suid binaries contained therein have an entry in > > that list. If a binary fails to have been registered, > > the Installer should complain loudly to the package > > maintainer. > 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. > >- /usr/sbin/checksecurity should compare the clearance > >list to the installed system and loudly complain to the > >system administrator if it finds any differences. > 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. > >- Additionally, the postinst script of that package itself > >should perform the same check and complain loudly. > double and tripple checks ? why ? 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. > [list of questions] > - what will happen, if the program has not the sgid/suid bit ? ACK. > yes. but also every sgid/suid bit that is not necessary > should be removed. Certainly. > i know, that some people do not like suidmanager, and so they don't use it. > they should be forces to use it, or write something better. ACK. tlr -- Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/ 2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How Debian Linux could be made more secure
Martin Schulze wrote: > I thought lintian already detects setuid binaries and needs > confirmation by the author that it needs to be setuser or > not. Not really. It warns for suid and sgid binaries in the package; but often, packages don't include such binaries directly. They call suidregister in the postinst, and use chown and chmod if suidregister is not available. Lintian would have to parse that in order to get a full list, and it doesn't do that (yet). Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How Debian Linux could be made more secure
i agree with you. a) every package should use suidmanager if it needs a 1000 2000 or 4000 bit. b) every package should document why it uses this special permission in /usr/doc//Security.Note (or README.Debian ?). c) security should be more important than functionality or featurism. remove the damned suid bit from all svgalib programs. everyone can use sudo or something like that ... >- The Debian Installer should check for every package, if > all suid binaries contained therein have an entry in > that list. If a binary fails to have been registered, > the Installer should complain loudly to the package > maintainer. 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. debian should do this, and not move the work to sysadmins. >- /usr/sbin/checksecurity should compare the clearance > list to the installed system and loudly complain to the > system administrator if it finds any differences. i agree. but /etc/suid.conf is fine, why an additional list ? >- Additionally, the postinst script of that package itself > should perform the same check and complain loudly. double and tripple checks ? why ? [list of questions] - what will happen, if the program has not the sgid/suid bit ? >As time proceeds, tools for (e.g.) testing for buffer >overflows should be made available. Their application by >package maintainers should be required. yes. but also every sgid/suid bit that is not necessary should be removed. for example : all svgalib games. everyone should use sudo or sometghing like that so he can restrict the access to a few trusted users. >As an additional level of "certification", packages may be >tagged "insecure" a package may not be insecure. either you install it in a secure way (e.g. svgalib games _not_ suid root), and tell the sysadmin how he can use it, and what risks he will have, or drop the package art all. security is more important than functionality or featurism. please start now : - document every sgid/suid bit - use suidmanager, so a sysadmin can turn something off - defaults settings should always reflect the secure setting, even if this breaks functionality. README.Debian should then tell how to enable some feature, and that this is insecure christian, did you count how often this was proposed ? i know, that some people do not like suidmanager, and so they don't use it. they should be forces to use it, or write something better. andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How Debian Linux could be made more secure
yeah, lintian might be cool, but it didn't make it into unstable until a week or two ago, so I haven't tried it... I don't know how I missed the 19217 bug report, but a fixed xcontrib is in Incoming as of a few hours ago; it didn't help the situation that xload was added back "late" after it fell out of one of the proc packages [which then switched maintainers, and *then* people noticed it was missing, oops :-)] So I think the only thing here was some last minute clumsiness, rather than anything pervasive. (I handed off the rest of X because I was already too busy, after all...) There is a kind of annoying tendency for people to take a bug report or two as a symptom of great conspiracies, it'd make me happier if we tried to avoid that... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How Debian Linux could be made more secure
On Tue, Apr 28, 1998 at 01:02:11PM -0500, Branden Robinson wrote: > > I thought lintian already detects setuid binaries and needs > > confirmation by the author that it needs to be setuser or > > not. > Yes, it does. Fine. But apparently this confirmation is given a little bit - mh - quickly. ;-) The aim of my suggestions is mainly the following: Make the package maintainers really _think_ about what privileges their packages need. Require them to give some reasoning about the privileges. Require peer review of these reasons. Make these reasons part of the packet's documentation. tlr -- Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/ 2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How Debian Linux could be made more secure
On Tue, Apr 28, 1998 at 07:59:49PM +0200, Martin Schulze wrote: > I thought lintian already detects setuid binaries and needs > confirmation by the author that it needs to be setuser or > not. Yes, it does. -- G. Branden Robinson | The first thing the communists do when Purdue University | they take over a country is to outlaw [EMAIL PROTECTED] | cockfighting. http://www.ecn.purdue.edu/~branden/ | -- Oklahoma State Senator John Monks pgpsBVTq84KOr.pgp Description: PGP signature
Re: How Debian Linux could be made more secure
On Tue, Apr 28, 1998 at 12:50:37PM -0500, Branden Robinson wrote: > On Tue, Apr 28, 1998 at 04:50:45PM +0200, Thomas Roessler wrote: > > First, the Debian Policy should be enhanced by a paragraph > > on suid binaries. The policy should emphasize the least > > privilege principle. It should require the use of > > suidmanager when installing scripts suid root. > > > > Further, the policy should require maintainers to tag bug > > reports about programs running suid root "critical". (You > > may also consider to add an option to the bug program > > which tags a bug report as a security problem, and thus > > "critical". This is also interesting for network programs > > which have security breaches and/or denial of service > > vulnerabilities.) I thought lintian already detects setuid binaries and needs confirmation by the author that it needs to be setuser or not. Regards, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / The good thing about standards is / / that there are so many to choose from. -- Andrew S. Tanenbaum / -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How Debian Linux could be made more secure
On Tue, Apr 28, 1998 at 04:50:45PM +0200, Thomas Roessler wrote: > First, the Debian Policy should be enhanced by a paragraph > on suid binaries. The policy should emphasize the least > privilege principle. It should require the use of > suidmanager when installing scripts suid root. > > Further, the policy should require maintainers to tag bug > reports about programs running suid root "critical". (You > may also consider to add an option to the bug program > which tags a bug report as a security problem, and thus > "critical". This is also interesting for network programs > which have security breaches and/or denial of service > vulnerabilities.) I thought we already addressed this somewhere, though if true it probably needs to me documented in a more conspicuous place. IIRC: root privilege exploits are severity "critical" user privilege exploits are severity "grave" denial-of-service attacks are severity "important" -- G. Branden Robinson | Measure with micrometer, Purdue University | mark with chalk, [EMAIL PROTECTED] | cut with axe, http://www.ecn.purdue.edu/~branden/ | hope like hell. pgpK7B1Ch8KG5.pgp Description: PGP signature
Re: How Debian Linux could be made more secure
On Tue, Apr 28, 1998 at 04:50:45PM +0200, Thomas Roessler wrote: > Today, I reported two bugs in debian packages which > install binaries suid root. Both bugs were avoidable: There's a third one too---we install xterm suid root, which isn't necessary (the alternative is to use a wrapper program to do pty allocation and utmp entry). This was mentioned on one of these lists a couple of months ago. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How Debian Linux could be made more secure
On Tue, Apr 28, 1998 at 04:50:45PM +0200, Thomas Roessler wrote:
> Further, the policy should require maintainers to tag bug reports about
> programs running suid root "critical".
>From http://www.debian.org/Bugs/Developer.html#severities
:critical
: makes unrelated software on the system (or the whole system)
: break, or causes serious data loss, or introduces a security hole
: on systems where you install the package.
Proper assignment of Severity: is IMHO a part of a maintainer's task
already; I don't think this needs to be spelled out in the policy.
> (You may also consider to add an option to the bug program which tags a
> bug report as a security problem, and thus "critical".
In that case, I hope "bug" will explain the meaning of the Severity level
chosen and ask for confirmation.
> - While installing packages, dpkg-deb(8) should consult the clearance list
> and warn the user about certain programs not being in the clearance list.
dpkg-deb is a archive packager like ar(1) or tar(1). The proper place for
this, if you want it integrated in the package management tools, would be
dpkg IMO.
> As an additional level of "certification", packages may be tagged
> "insecure", depending on previous experience or the level of review (e.g.,
> the BSD lpr, xbase, and sendmail packages may be tagged "insecure", while
> qmail is tagged "secure"). The installation procedure could then ask the
> user for the system's security level and warn him if he tries to install a
> package with a non-appropriate certification.
I object to these labels. Auditing source is a good idea, but even thorough
audits are IMO not strong enough a method to base a label "secure" on
("tested", "audited", "previously audited" or whatever are OK by me).
Perhaps it would be better to differentiate between several sources people
can use to base there trust on (like PGP's feature of calculating trust on
the basis of a personal parameter of trust per signator).
Ray
--
Tevens ben ik van mening dat Nederland overdekt dient te worden.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
