--------- Received message begins Here ---------
"Albert D. Cahalan" <acahalan@cs.uml.edu>:
> Joseph Gooch writes:
> > [Albert D. Cahalan]
> >> Jesse I Pollard, II writes:
> >>> [Albert Cahalan]
> >>>> Jesse I Pollard, II writes:
> >>>>> "Albert D. Cahalan" <acahalan@cs.uml.edu>:
> >>>>>> Jesse I Pollard, II writes:
> >>>>>>> Pavel Machek <pavel@suse.cz>:
>
> >>> The "proper" search tool requires me to read the header of each
> >>> file in the system to determine if it carries any embedded
> >>> capabilities. This takes too long on large file systems.
> >>
> >> No, you have no reason to care about that. Do you also scan
> >> to code itself to see if it might try to delete your files?
> >> An elfcap executable is inert without the setuid marking.
> >
> > Setuid doesn't tell me anything about the executable. It might
> > have null capsets, it might just inherit caps, it might drop
> > everything. Who knows unless you check.
>
> Sure. If you worry about this, then you'd better also worry about
> the content changing. You'll need to read the whole file to verify
> that it has not changed. All 3 systems are alike in this way.
Not really - in a properly implemented capability system, ANY write
to an executable clears all capability lists, as it is a new executable.
> >> Why is it that you worry your security admins might put the
> >> setuid bit on random files? This is insanity. Such admins are just
> >> as likely to set capability bits on random files -- then what?
> >> Each case is as auditable as the other.
> >
> > Precautions would have to be taken to ensure that changes to a
> > setuid executable will drop the setuid bit. Otherwise if someone
> > got write access to the executable you'd be in trouble.
>
> This should be the case already for setuid executables.
> If not, we have a minor existing security problem.
>
> Anyway, "if someone got write access to the executable you'd be
> in trouble" is always true, under any system.
Yes/no - Yes if it is uncontroled, No if the kernel clears all capability
entries on write. Which is what it should do.
> >> Yes, that is exactly the problem. Apps often allow special access
> >> for UID 0, but you wanted to make UID 0 be a normal user.
> >> Remember that client apps may pass credentails over a socket,
> >> so you may end up with fully privileged code granting unintended
> >> access to the user with UID 0.
> >
> > Once one or all of the three methods are available the securelevel
> > can change and UID is no longer god. No argument here.
>
> Securelevel won't fix apps that trust UID 0. It fixes the kernel.
> I'd say don't even bother, since it is safer to just avoid UID 0.
> Actually, do a kernel panic if something changes UID to 0. Such
> a change indicates that security-critical software has a bug.
Removing the power of root is what fixes that.
> >>> No it doesn't. The user can still set the bits in the executable.
> >>
> >> Those are meaningless bits.
> >
> > Trojans happen all the time because people aren't aware of
> > certain events. Changing the bits around here is no different.
>
> Yep. If you are going to check capability bits, you ought to
> also check that the executable hasn't been modified. You might
> as well do both at the same time, and elfcap makes it easy.
> You can use the existing "tripwire" program to watch elfcap bits.
>
> >>> No it isn't - there is no change to the filesystem. The
> >>> bits are already there. That is one of the known problems
> >>> with carrying disks from one
> >>
> >> I don't see the feature in Linux 2.2 at all.
> >
> > Ok sure make me look it up.
> >
> > "Extended Attributes are arbitrary name/value pairs that are
> > associated with files or directories. They can be used to store
> > system objects (e.g., Capabilities of executables, Access Control
> > Lists) and user objects (e.g., the character set or mime type of
> > a file). Access Control Lists are implemented as extended system
> > attributes."
>
> That looks like IRIX, not Linux. Maybe you have a patched kernel.
Its part of the ext2fs file system structure. It resides on disk, not
in memory - the Linux VFS doesn't pass it yet.
> >>> I would prefer the in-memory system (especially to the elfcap one),
> >>> although I think it should use a memory mapped file instead of
> >>> memory only.
> >>
> >> Such a file would be one more thing to protect. The only reason
> >> to bother would be kernel memory limits, but one shouldn't have
> >> hundreds or thousands of privileged executables anyway.
> >
> > The only problem with the in-memory model is the need to reboot
> > to make changes. Some might consider that a feature, I do not.
>
> Yes, this is a feature. I suppose you could allow a capability
> bit for adding new executables to the list. You could use the
> same bit currently used to modify running processes.
It is a feature, but modifications to the list could be done in
single user mode (I don't consider going down to single user mode
and back a reboot).
> >> What do you mean by this? The in-memory list would block any
> >> attempt to replace the files. The files are immutable. If you
> >> refer to the initial list, as loaded by LILO or init scripts,
> >> then there are ways to deal with that too. Missing files could
> >> halt the boot. Cryptographically strong checksums could be
> >> verified during boot.
> >
> > This is a lot of overhead for something easily put in the filesystem.
>
> Well, you don't really _need_ to verify checksums. You might want
> to do it though, under any of the 3 systems.
>
> > I grow weary of this favorites match and none of us are going to
> > convince each other anyway.
>
> Nobody will convince me to like the filesystem-based bits, but
> I'm starting to really prefer the in-memory system. Filesystem
> changes are a last resort, perhaps "needed" for MAC and ACLs.
> There just aren't enough privileged executables to bother with
> the trouble of dealing with incompatible filesystem changes.
> If every data file needed capability bits, I'd think otherwise.
> Locking 100 inodes into memory is reasonable; 654321 is not.
Needed for MAC certainly, but to support MAC you also need capabilities
in the file system too just to have a single audit/verification path.
Otherwise you have more than twice the amount of work to do.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:10 EST