Linux-Development-Sys Digest #640, Volume #6 Wed, 21 Apr 99 08:14:28 EDT
Contents:
Re: Glibc rant ("G. Sumner Hayes")
Re: Glibc rant (Andy Isaacson)
Re: About jiffies (Peter Samuelson)
Re: Trusted Linux ("G. Sumner Hayes")
Re: 2.2.6 kmem_free: bad obj addr (Marc Lefranc)
Re: "Permission denied" (Peter Samuelson)
Re: A Technical Question about the MBR Boot code. (Villy Kruse)
Re: SMP, interruptible_sleep_on and spinlock (Lorenz Hahn)
Re: saving program state with core files (Maciej Golebiewski)
Re: Problems getting APM to work with 2.2.5 ("Andre Malafaya Baptista")
Re: HELP! Something Wicked happened! (Jeff McWilliams)
----------------------------------------------------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Glibc rant
Date: Wed, 21 Apr 1999 02:32:47 -0400
Andy Isaacson wrote:
>
> In article <[EMAIL PROTECTED]>, G. Sumner Hayes wrote:
> > glibc-2.1 is the first public release of glibc2. 2.0 was an
> > experimental series for developers. It's hardly surprising that
> > there
>
> No...
Yes...
> While there was a 1.99 series of development releases which was used
> on Linux/Alpha and Linux/PPC (and others?), and which did have some
> stability problems, the 2.0 series was certainly not "an experimental
> series for developers". Or at least, this is the first claim I've
> seen to that effect.
Next time try reading the README, or the release notes, or the FAQ.
The first line of the README:
> This directory contains the version 2.0.6 test release of the GNU C
> library
The release notes said:
> GNU libc 2.0 is titled "experimental". We are not yet ready for the
> general use. This will take some more weeks. But we are ready for a
> much wider audience. The code in the libc should be pretty stable.
The (dated) FAQ at
http://www.gnu.org/software/libc/faq-index.html says:
> Version 2.0.6 is currently in testing to fix a few minor problems.
> This will hopefully be the last release before the version 2.1
> release. Version 2.1 will be the official stable release.
--Sumner
------------------------------
From: [EMAIL PROTECTED] (Andy Isaacson)
Subject: Re: Glibc rant
Date: 21 Apr 1999 05:03:44 GMT
In article <[EMAIL PROTECTED]>, G. Sumner Hayes wrote:
> glibc-2.1 is the first public release of glibc2. 2.0 was an
> experimental series for developers. It's hardly surprising that there
No...
While there was a 1.99 series of development releases which was used
on Linux/Alpha and Linux/PPC (and others?), and which did have some
stability problems, the 2.0 series was certainly not "an experimental
series for developers". Or at least, this is the first claim I've
seen to that effect.
Got any references?
-andy
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: About jiffies
Date: 21 Apr 1999 00:42:00 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[new.ccu.edu.tw <[EMAIL PROTECTED]>]
> I'm reading one book about Linux Kernel, and it said that the
> constant HZ (<linux/param.h>) determines the frequency of timer
> interrupt.
Yes.
> When timer interrupt occurs, the handler will increment the variable,
> jiffies. I heard before that 18.2 ticks equal to 1 sec. But the
> default value of HZ in Linux on x86 is 100. Why ? Why not 18.2 ??
Because 18.2 would be much too slow for many purposes. For example,
task preempting only happens on timer ticks, and on many systems it
would be quite noticeable if that only happened twenty times per
second. Also, many device driver timings are measured in jiffies, and
in some cases the resolution needs to be a lot better than 18.2 Hz.
So what is special about 18.2? Well, the BIOS sets up the clock chip
to that when you boot. Your operating system is free to make alternate
arrangements.... (Then again, I'm not sure whether Linux resets the
18.2 timer to 100 or just uses a different one. The clock chip has at
least three different timers on it.)
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: Trusted Linux
Date: Wed, 21 Apr 1999 04:56:10 -0400
Peter Samuelson wrote:
> [G. Sumner Hayes <[EMAIL PROTECTED]>]
> > 1. It only works for some types of binaries -- ELF is okay, but
> > a.out, coff, and other formats are still used by many people. I
> > don't see it as a given that ELF will never be supplanted, either.
>
> Requiring capability binaries to be ELF is not too much more to ask
> than, say, requiring that they be on a particular type of filesystem.
Depends on perspective, I suppose. I may have an important daemon
that's only available as a SCO binary that needs to bind a low port;
not having source code, I don't want to give it setuid root status.
Some people still use a.out (with new kernels, no less) -- among other
things, it is slightly faster and some don't want to break backward
compatibility. Many people use non-Linux binaries, particularly
Alpha and Sparc users; if you have to run binaries that you don't
have source for, limiting their priviledges is especially important.
> > 2. It requires overloading the meanings of either suid or sticky
> > bits and violating the principle of least surprise WRT said bits --
> > either a program that is setuid root doesn't really run with UID
> > root (breaks some security scanning programs and people)
>
> Using the sticky bit or immutability bit would be sick and wrong, but
> only checking caps on `setuid root' would not pose so much of a
> problem. After all the process is now getting *fewer* privileges than
> it looks like, not more. So yes it violates the PLS but not too much.
Keep in mind that most capable programs shouldn't run as UID 0; many
daemons want UID 99, for instance. So, how do I have a program run:
1. With UID=0 and no capabilities.
2. With UID=0 and bind-low-port capability.
3. With UID=99 and no capabilities.
4. With UID=99 and bind-low-port capability.
5. With UID of whoever execs it and no capabilities.
6. With UID of whoever execs it and bind-low-port capability.
Hmm. I guess you'll have to put the real setuid into the ELF headers.
But now you've confused the people and tools who look at it and
think owner=0 and setuid means setuid 0. Violation of the principle
of least surprise. You've also broken the semantics completely;
there's no way to grant root SETUID capability and not FCAP capability.
That's a real problem, since in a secure system you want to make sure
that nobody has FCAP capability under normal circumstances (only when
special security maintenance is needed, by putting a physically disjoint
disk in that has an FCAP-enabled setup on it.). You could disallow
SETUID unless you also have FCAP if uid==0, but that makes no sense --
UID 0 should probably be able to create bins that run as itself. So now
you could have the kernel clear the capabilities from the header if
UID=0 and there's no FCAP power, but you've just put libbfd into the
kernel and still don't have the semantics right yet. Now you need the
guy who handles security software updates to have FCAP power, but he
doesn't want to be wandering around with chown_other power nor
altering his uid to 0 because that breaks the other major part of a
trusted Linux (auditing) in non-trivial ways.
The more you think about it, the more problems you have trying to
figure out a way of doing this that gives you the power and security
of the capability system without having any of the common capabilities
be equivalent to root (which defeats the purpose of having capabilities
to a large extent) and without breaking auditing (and hence making
B2 security certification impossible a priori) because of the bogus
semantics.
The problem is simple: you're used to setuid 0 meaning priviledges.
In a capabilities-based system, setuid and raised capabilities are
orthogonal. All the problems you hit in the setuid-based system are
because of this. Even the capabilities-in-ELF-section people on
linux-kernel have abandoned using the setuid bit and gone to some
bizarre combination of the sticky bit and the immutable bit -- if both
are set, then the elf-headers are used. Of course, that has its own
problems: how many NFS servers/clients can cope with extended
attributes such as immutable? The NFSv4 proposals have a draft
that deals with the issue, but AFAIK nobody has implemented it. Linux
hasn't, for sure. So you're no better off than a true
capabilities-in-fs solution on that front, and you've still got some
weirdnesses to contend with (sticky bit isn't priviledged, granting
the power to set the immutable bit is equivalent to FCAP, etc). And
you're limited to ext2, just as a caps-in-fs solution is limited to
one fs.
This is far and away the most important of these points as far as
I'm concerned; the others are basically backwards-compatibility
problems that aren't deal-breakers and could theoretically be dealt
with.
[efficiency argument dropped; no numbers, so it's no worth talking
about]
> > 4. It requires violating the ELF specification to interoperate
> > securely with older kernels.
>
> The new binary would run setuid root on an older kernel,
Which is the problem. I already have binaries on my machine that I
run with certain capabilities on 2.2.x but don't allow to run as root
on 2.0.x; I have nasty hacks in my init scripts running around to fix
up priviledges. The caps-in-elf-section patches allow for elf binaries
with FLE in place of ELF magic, a gross hack but the only way they
could find to prohibit capability-enhanced binaries from running on
capability-free kernels.
(if you're wondering, I grant mlock priviledges to a crypto daemon
on 2.2.x, but not on 2.0.x; the daemon is still useful on 2.0.x, but
not as resistant to attacks on the encrypted data/keys; that's I
tradeoff I prefer so that foreign attackers have a lower probability
of entering the machine in the first place and getting root powers
if they do]
[next point dropped]
> > 6. It completely breaks tripwire and other intrusion-detection
> > programs and makes them nearly impossible to implement without
> > putting a ton of knowledge about various binary formats into each
> > such tool.
>
> Presumably tripwire et al already check for things that are setuid
> root. So ... they would continue checking for things that are setuid
> root. It would *not* be difficult to write a short utility that could
> set and show cap masks for a file, and any libbfd hacking crap would
> be confined to that program. (A glorified `ls -l' + `chmod u+s', if
> you will.) tripwire would use it, the sysadmin himself would use it,
> and most tools would ignore the issue and treat cap-binaries as normal
> setuid root, etc.
You misunderstand. Tripwire (and brik and rpm and md5sum and others)
calculate md5 hashes (or PGP signatures or similar) of all the binaries
on the system. They tell you if a binary is tampered with. Setting
or altering the priviledges will break all of these md5sums, which is
a mixed bag; it seems good to know that the caps have changed, but it's
bad to have no way of verifying whether the binary has changed
independently of the metadata. The way some of these tools are used
makes this a big pain in the butt.
Some license managers use hashes to make sure that the bins haven't
been tampered with; binaries you don't have source for are ones for
which it's most important to grant minimal priviledges.
> > An in-fs solution breaks NFS, but that's not a big deal
>
> It also breaks fs compatibility with older kernels. That *is* a big
> deal. It is conceptually cleaner, but in practice a lot of userspace
> would need patches. (The same sorts of patches you need when you
> start putting ACL's in the filesystems. Perhaps both ideas should be
> implemented as one big fs interface change.)
Implementing caps alongside of ACLs is the plan, and one that I
advocate. AFAIK, this is planned for ext3 (along with journalling and
a few other things) and will be downward compatible with ext2 -- the
only reason to rename to ext3 is to avoid tampering with the mainline
ext2 code and introducing bugs into it. I believe ReiserFS is also
looking at ACL/caplist support. Consider my ext3 and ReiserFS
statements to be highly speculative and possibly wrong, though. Talk
to SCT or Hans for real information.
My position: Capabilities are a chance to substantially decrease the
number of important problems coming across Bugtraq. They're the sort
of new interface that you can't re-invent every day, so you'd best do
it right the first time. Implementing capabilities in a way that
doesn't help security is harmful in terms of time wasted and of the
false sense of security it gives you. A scheme where things still have
to run with UID 0, or where one common capability will automatically
grant all the others, or where root can't be properly limited in power,
is not really worth implementing. This is a chance for a fairly
substantial increase in security if done right; let's not blow it.
--Sumner
------------------------------
From: Marc Lefranc <[EMAIL PROTECTED]>
Subject: Re: 2.2.6 kmem_free: bad obj addr
Date: 21 Apr 1999 12:00:23 +0200
Trevor Bradley <[EMAIL PROTECTED]> writes:
> Got this last night...
>
> Apr 18 04:40:05 phobos kernel: kmem_free: Bad obj addr (objp=c0de8760,
> name=dentry_cache)
> Apr 18 04:40:05 phobos kernel: Unable to handle kernel NULL pointer
> dereference
> at virtual address 00000000
> Apr 18 04:40:05 phobos kernel: current->tss.cr3 = 0094e000, %cr3 = 0094e000
> Apr 18 04:40:05 phobos kernel: *pde = 00000000
The only times I have seen such error messages is with overclocked
systems. If you insist on keeping your processor at 133, you might try
to increase the wait states of your RAM.
Marc.
--
_____________________________________________________________
Marc Lefranc, Charge de Recherche au CNRS
Laboratoire de Physique des Lasers, Atomes, Molecules
Bat P5, UFR de Physique
Universite des Sciences et Technologies de Lille
F-59655 Villeneuve d'Ascq CEDEX (FRANCE)
e-mail: [EMAIL PROTECTED] ; FAX : +33 (0)3 20 33 70 20
_____________________________________________________________
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: "Permission denied"
Date: 19 Apr 1999 21:22:01 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Bill Zimmerly <[EMAIL PROTECTED]>]
> I don't know whether or not my email server was hacked, there were a
> few failed telnet attempts in the log prior to the "crash", but
> clearly when the machine came back up, I was in trouble.
Sounds like someone got in -- or at least did some sort of successful
DOS that rebooted your box.
> inetd[232] ftpd/tcp bind: Permission denied
> inetd[232] telnetd/tcp bind: Permission denied
> inetd[232] pop3d/tcp bind: Permission denied
It looks very like inetd isn't running as root. Check. (`ps U root'
or, if you have a Unix98 ps, `ps -fu root'.)
> What files are needed by "inetd", "bind", or the aforementioned
> daemons???
The `bind' above refers to binding a port, not to the Berkeley Internet
Name Daemon. Your problem is internal to inetd.
> I looked at the "inetd.conf" file and all seems to be okay. "root" is
> how these processes are started! HELP!!!!!!!
inetd is having the problem *before* it starts any processes. Check to
make sure inetd really is running as root.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Crossposted-To: alt.linux
Subject: Re: A Technical Question about the MBR Boot code.
Date: 21 Apr 1999 08:57:30 +0200
In article <[EMAIL PROTECTED]>,
John Smith <[EMAIL PROTECTED]> wrote:
>1) It says that the the BIOS start up loads the MBR code at address
>0x7C00 -- this is the RAM memory address right?
This is correct.
>2) It also says that the MBR code is moved from the address 0x7C00 to
>the address 0x90000 -- I've been wondering for ages why it needs to move
>the code. WHY? And why must it move it to the specific address 0x90000?
>Why not some other address?
Considering that the bios reserves the area above 0xa0000 the 0x90000 is
a nice round number where to load the boot code at and it will still fit
below the bios area. It could be loaded at a lower address, but the
higher address you load the boot code at the more free area you get for
loading in the linux kernel.
Villy
------------------------------
From: Lorenz Hahn <[EMAIL PROTECTED]>
Subject: Re: SMP, interruptible_sleep_on and spinlock
Date: Wed, 21 Apr 1999 10:22:00 +0200
Hi,
> Try it this way. Use an actual Linux kernel semaphore, not the wait/wakeup
> mechanism.
>
> Background:
> close interrupts
> do some checks
> if interrupt has not arrived
> tell ISR that I'm waiting
> open interrupts
> down(&semaphore)
>
> Interrupt:
> do some initial clean up
> if process is waiting for me
> up(&semaphore)
>
> The order of the "down" and "up" don't matter with semaphores.
thank you Dave, this was it. I've upgraded a existing driver for Linux 2.0.x
for usage with 2.2.x and SMP. Without SMP (cli;wait;sti) behaves like a
semaphore, but with SMP it doesn't. After recognizing the semaphore structure
I also recognized up() and down() and solved my problem.
Regards, Lorenz.
--
Lorenz Hahn email: [EMAIL PROTECTED]
SYSGO RTS GmbH, Carl-Zeiss-Str. 41 phone: +49 (0) 6131 9138-46
D-55129 Mainz / Germany fax: +49 (0) 6131 9138-10
PGP public key fingerprint: 5E 51 B2 DF DF E2 49 AD BD 7A FC 26 3F 19 58 25
------------------------------
From: Maciej Golebiewski <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.development.apps
Subject: Re: saving program state with core files
Date: Wed, 21 Apr 1999 10:20:06 +0200
Markus Wandel wrote:
>
> In article <[EMAIL PROTECTED]>,
> dementen <[EMAIL PROTECTED]> wrote:
> >Hi,
> >
> >I want to be able to save the state of a program (like a game for
> >example) during its running and after to be able to load this state to
> >continue the process at another time.
[snip]
> I don't _believe_ this can work (I'd be happy to be refuted by someone who
> knows better.) Based on my understanding, a core file saves the memory image
> and register contents, but it does not save kernel data associated with the
> process. So open files, IPC structures, running timers, etc. cannot be
> preserved. This includes current audio driver settings (if open), connections
> to the X server (not even considering the data only the X server knows, like
> configuration of the windows etc.), network connections, as well as plain old
> disk files.
There is a software package called Condor for migrating Unix processes
between workstations. I have impression that they are doing this by
generating coredumps and then resuming on another machine from a core
dump. It should be good idea to see what they have done. On the other
hand I have impression that there are some restrictions on the programs
that can be migrated by Condor: even if they are able to restore
(on resume) the file descriptors properly, I don't think this will be
possible with e.g. sockets etc. So resuming from a core-dump should
work,
but only for some applications (e.g. number crunchers should be OK,
games probably not).
Regards,
Maciej
------------------------------
From: "Andre Malafaya Baptista" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Problems getting APM to work with 2.2.5
Date: Wed, 21 Apr 1999 13:04:59 +0100
Dear Eric:
I was/am having the same problem.
I posted this same problem on one of this Linux-related newsgroups and a
reply popped up.
The author of the message was the responsible for the APM on Linux (Michael
Wagner, if I recall correctly). He said that that feature was missing on
2.2.x kernels because of lack of time before the 2.2.x release. If you
really want that feature you might take the risk and go on to the 2.3.x
kernels.
HTH,
Andr�
Eric <[EMAIL PROTECTED]> wrote in message
news:cvcT2.2199$[EMAIL PROTECTED]...
> I've recently tried upgrading to Kernel 2.2.5, but am running into a
couple
> of problems. I'm running RH5.0, with all the upgrades as per the 2.2
> changes doc.
>
>
> My is with the APM. I am upgrading from 2.0.32. I'm running
> this on a PII (ATX motherboard), but for some reason, the "poweroff on
> shutdown" feature doesn't work with 2.2.5. Under kernel 2.0.32, it would
> automatically poweroff my PC, but 2.2.5 just displays the "System halted"
> message. The system is running on an Asus P2B motherboard. Are there any
> special things I have to do to get 2.2.5 to auto-powerdown the system?
>
> I've installed the new syslogd and klog daemons, as well as the new
sysvinit
> toolkit (which has the new halt -p functionality, etc), but they don't
seem
> to make any differences.
>
> Does anyone know what I can check or do to get my PC to auto-power-off
upon
> a halt -p or a shutdown -h command?
>
> Thanks!
>
> Eric
> [EMAIL PROTECTED]
>
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Jeff McWilliams)
Subject: Re: HELP! Something Wicked happened!
Reply-To: [EMAIL PROTECTED]
Date: Wed, 21 Apr 1999 12:08:07 GMT
In article <7fjkkt$q7a$[EMAIL PROTECTED]>, Peter Samuelson wrote:
> [me]
>> > Have you read Richard Gooch's Kernel Newsflash page?
>[Jeff McWilliams <[EMAIL PROTECTED]>]
>> Thanks, Peter. I'll get the latest kernel, apply the patch, and see
>> what happens.
>
>...and suddenly it occurred to me that you did not mention which kernel
>you were running. I assumed this was a 2.2.6 problem, which is what
>the Kernel Newsflash page was created to address (problems with
>brand-new kernels). If you're still running 2.0.x, don't rush to
>upgrade -- Donald Becker tries hard to keep his drivers running for
>multiple kernel versions, so you should just look on his site (address
>should be in your driver) for an updated version.
>
Huh, yeah, I did forget to mention that. 2.2.4 at this point. Will
go to 2.2.6. Thanks.
jeff
--
Jeff McWilliams - Advanced Development Engineer, ACE Technologies
[EMAIL PROTECTED]
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
