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.
>> 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, 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.
>>> 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.
>>> 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.
>> 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.
I grow weary of fixing your word wrap problems. Please get a
more reasonable MUA or editor. Emacs works, with or without elm.
-
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 : Thu Jun 15 2000 - 21:00:33 EST