lkml.org 
[lkml]   [1999]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Capabilities, this time in elf section
Hi Albert,

On Thu, 15 Apr 1999, Albert D. Cahalan wrote:

> >>> Then you haven't been paying attention, Albert. After the modification, a
> >>> 2.2 kernel will interpret 'chmod +t' as 'capability enable'; this will
> >>> require the current process has CAP_SETFCAP, and on success will set
> >>> _both_ sticky and immutable on a local fs. (or just sticky on remote).
> >>> Otherwise neither is set.
>
> Woah. Stop right there. You plan to _automatically_ set the immutable
> bit when the sticky bit is set? If a copy or unpack an executable with
> the sticky bit set, I won't be able to remove it? Oh crap!

Sure, if you have CAP_SETFCAP, you should be able to remove both in a
whack. Likewise, if you have write access to the file, writing should
clear both. Since the kernel currently has _no_ policy for the sticky
bit, I think implementing these shouldn't be a problem.

> If sticky alone is good enough for a remote filesystem (it is not),
> then why bother with the immutable bit at all? This makes no sense.

The immutable bit was introduced to prevent the 'old kernel' problem;
i.e., so that users on the same box couldn't cap-enable their binaries.
Mounting a remote fs and honoring heightened capabilities from it is a
security risk in any event; I suggest 'cap_squash' be the default, much as
'root_squash' is now.

> > No kidding. If you're running with this new security model, you should
> > re-think running system binaries over nfs. This, btw, is not just my own
> > opinion.
>
> This is not acceptable.

If you can trust the sticky bit remotely, do so; if not, don't. I have no
problem with this, but this is apparently just a genuine disagreement
between us, which is fine.

> > I've tried to avoid using 'bad' unless I was saying something like
> > 'marking named(8) is bad', which is obvious. You have to say _why_ it's
> > bad if it's not obvious. It only seems so obvious to you because you
>
> OK, using the sticky bit as a flag is just absurdly bad because it
> lets anyone with access via Irix grant themselves full capabilities.

OK, but why are you mounting an fs w/ Linux-elf executables and honoring
raised priviledges from an IRIX server? Now, with either scheme you could
have a mount option that honors the file inheritable set only. Not
terribly secure in either event, but maybe worth more thought.

> > haven't really given more than a few second's thought to the solution,
> > evidenced by your misunderstanding about the immutable bit relationship.
>
> I'm not some kind of vegetable you know... (rudeness not appreciated)
> While I think you are terribly wrong, I acknowledge that you have given
> more than a few second's thought to the solution. I have too.

Not everybody has done their homework on this stuff before speaking up. I
now see that you obviously have done the required reading.

> >> Imagine a Linux distribution that had this misfeature. It gets installed
> >> on some new systems on the network. I sit down at my old Linux box,
> >> make a nice executable, telnet to a new box, and do bad things. Yow!
> >
> > What the HECK are you talking about? You sit down at a Linux box that is
> > exporting /usr to a new box? Then you edit the binaries on /usr (or
> > create new ones) that do bad things on the new box?
>
> Forget /usr, anything will do. Consider /projects/trauma instead,
> where local users are developing a game that needs CAP_SYS_RESOURCE.

If the game is meant to be run by normal users, then you don't want a
normal users' bash process to have CAP_SYS_RESOURCE in it's inheritable
set; then _any_ process can inherit it. Rather, you want it in the
permitted set. This means that your game developers will need the ability
to mark a file 'setuid root' anyway, so they can set whatever they want in
_either_ scheme.

Now, I have a suggestion that should apply equally to either solution; it
could be possible to specify in a mount option masks for permitted and
inheritable. This would limit the actual capabilites the mount would
honor. This could be nice for either implementation.

> > If you can do that,
> > then you might as well just create a whole fleet of setuid-root binaries.
> > If you can't trust the /usr on another machine completely, you damn well
> > shouldn't be mounting it over nfs!
>
> I can trust that normal users won't create setuid-root executables.
> This is all the trust I need.

OK, I haven't really completely understood the whole nfs problem untill
now. My bad. You last sentence made it clear to me. Worse, it could be
ugly to code the correct mount options into the _client_. Best I can do
now is cop-out and say that caps in fs metadata won't work over nfs in any
case. I _still_ want a correct implementation of capabilities to use.

> > Yes. Please go read and think and understand why a mis-implementation of
> > capabilities is at best a small step forward in security, and a large step
> > backward for adminstrators who will one day have a correct implementation
> > of capabilities to work with. (ext3 + cap metadata)
>
> I doubt that all UNIX systems will add support for Linux capabilities
> to their NFS servers and local filesystems.

You're right here. But this is still just a disagreement; I don't want to
mix old setuid-root is special with new capability-based security. You
do.

> >> That is beauty, not ugliness. I can have 4 UID values if I want.
> >
> > That's an abomination, and now you're screwing around with traditional fs
> > rights. Again, just _try_ to get this code in the kernel. No way.
>
> Screwing around with traditional fs rights in what way? The executable
> is owned by root and nobody else. This is very simple. (someone else
> had the idea to put some kind of "real" owner in the file, not me)

Ah, you're referring to real, saved, effective and fs uid, I guess. I
don't see any good reason to screw with the old semantics.

> > setuid0:
> > - setting inheritable caps is a non-priviledged operation, but it should
> > be. (this means that, in many cases you have to remove all write rights
> > to the file, otherwise the file owner can always max-out inheritable)
>
> The kernel already clears the setuid and setgid bits on write.
> (note that the sticky bit is not cleared in the same manner)

I also suggest that sticky/immutable semantics clear both on write, when
write would otherwise be permitted by the fs rights. Again, I'm just
giving the kernel a reasonable interpretation of a bit that it previously
didn't care about.

> > - if you want to set permitted, you have to make the file setuid root;
> > setting permitted is a good idea for things like 'named' as I've shown.
> > - if the file is not setuid root, you use the uid and setuid bit from the
> > filesystem, otherwise you read it from the binary. this is an ugly break
> > in UNIX fs semantics.
>
> I don't suggest putting a setuid bit in the binary. Check my code.
>
> Linux supports 4 UID values. The header always sets all 4 of them.
> They may be set to any value, including 4 special values that
> represent the old UID values.

Well, you've just gone and completely thrown away the old semantics for
the operation of the setuid bit if the file is marked setuid-root. The
sticky bit solution merely preserves the old semantics completely, except
setuid-root no longer grants all caps. It just gives the process root's
rights in the fs, which currently would be a bad thing. (I wouldn't
suggest making capability-enabled binaries setuid-root under the sticky
bit scheme/)

> This is a beautiful system.

I _strongly_ disagree here. I don't like breaking old semantics when
unnecessary. root=god -> capabilities is a well-defined transition in
semantics, I don't think would should break other stuff.

> > Albert, in particular you don't seem to understand just how important the
> > inheritable bits are in a capability-based security system, and how bad it
> > is to not require setting them to be priviledged. Or at least, if you
> > want it to be priviledged, now you have to mark it setuid root.
>
> Which inheritable bits, file or process?

File.

> It would be very bad to let a
> user set or clear bits in either one.

Right, but so far (according to my threads with Richard Gooch and Pavel
Machek) any file that isn't setuid-root will still have it's inheritable
bits honored. This would mean any file could inherit rights from the
admin. With the sticky bit solution, a paranoid admin (or distribution
maintainer) could configure the kernel to use default inheritable of 0,
and only honor inheritable on a file that has been capability enabled.
(which in this system is a priviledged operation). Yes, the distribution
maintainer would have to set caps for _every_ file with a legitimate right
to inherit caps, but I think it would be great to be able to do that. An
admin would be virtually immune from trojan binaries on the local fs.
('sl -Fla' anyone? ;-)

> It is perfectly fine to use the
> setuid bit to mark any "interesting" files, and a very good idea too.
> Safety is ensured by the mangled header.

Well, yes, you can mark cp, tar, etc... as setuid-root, and that would
work just fine to securely set inheritable bits. But this is a
compatibility nightmare; don't _EVER_ boot to an old kernel. Eric
Biederman suggested the immutable bit specifically to make it safe to boot
to an older kernel. You also don't want all these extra setuid-root
binaries on a remote-mount fs.

> Here is a normal user process:
>
> CapInh: 00000000fffffeff
> CapPrm: 0000000000000000
> CapEff: 0000000000000000
>
> If you can freely set the inheritable bits on a file.
>
> pP' = fP | ( fI & pI )
> pP' = fP | ( 00000000fffffeff & 00000000fffffeff )
> pP' = fP | ( 00000000fffffeff )
> pP' = at least 00000000fffffeff, which is almost everything
>
> The same goes for fP. They are about the same in fact, since you can't
> safely remove bits from pI.

I don't understand 'can't safely remove bits from pI.'...

> I can see why the POSIX committee might
> reject such a system, and perhaps we should respect their rejection.
> The more I study this system (including kernel code) the worse it looks.

I honestly don't know why it was rejected. I can only say that,
implementing with sticky/immutable makes it look very good to me. And the
support is mostly in the kernel already.


It seems we have some genuine disagreements, but at least I feel our
latest exchange has been productive. I'm sorry I was a bit rude in my
last message.

In any event, I think it's time others took the time to understand the
issues involved and weigh in with other educated opinions.

cheers,
David

- --
David L. Parsley
Network Specialist
City of Salem Schools


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:1.369 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site