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>:
>> You'd better explain what kind of "audit control" you are
>> expecting, because this doesn't make any sense to me.
>>
>> Do you want to look for privileged executables? If so, elfcap
>> is little different than inode-based bits. You can use the
>> proper search tool in either case. Elfcap does have the advantage
>> of giving you a quick check via regular "find" though. The real
>> winner here is the in-memory system, since the kernel could provide
>> a list via /proc.
>
> 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.
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.
>> Do you want to to record creation of privileged executables?
>> No problem, this comes free with setuid-creation data.
>
> Nope - the privilege bits are still set, the image just doesn't
> have the setuid bit set yet. Any file containing these bits are
> a potential trojan.
What are you smoking? Any file that does "rm -rf /" is a trojan
too, and I certainly hope you don't have root running such stuff.
By your criteria, any file at all is a trojan. One of your crazy
admins might look at /bin/rm and think, "hey, that needs to be
able to delete any file, so I'll just grant it DAC override".
>>>>> they may have passed the initial testing and appear as quite normal
>>>>> applications UNTIL they are run as root. Even on a system with root
>>>>> having no privileges, suddenly this program becomes privileged.
>>>>
>>>> See, there is your mistake. It is foolish to think that it is
>>>> practical to have root without privileges. Just disable the account.
>>>> (set the password entry to '*' or adjust the kernel as desired)
>>>
>>> Works fine on many systems.
>>
>> I'm sure it works "fine" until an app screws up. The world is
>> filled with code that assumes UID 0 is special. You aren't serious
>> about security until you stop allowing UID 0 processes.
>
> app screws up..??.. I have yet to see an app that depends on uid 0 for
> proper operation. I have seen some that use it to determine whether to
> do additional things (sendmail is one).
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.
>>>> One should also maintain control over setuid executables by blocking
>>>> their creation, blocking their use with mount options, auditing the
>>>> use and creation, etc.
>>>
>>> Creating a setuid program should be prevented by the system as a security
>>> violation in the first place.
>>
>> Eh... so should creating a capability-enhanced program under
>> your preferred design. Exceptions must be made in either case,
>> otherwise you couldn't even install the system.
>
> No. Initial installation is done during single user mode (all
> capabilities set). After multiuser mode is started, that is cleared
> (and at the beginning of the multi-user startup too). To install
> privileged programs first requires the process (shell) to be
> authorized by the system/security administrator. The user so
> authorized must log in, using the proper procedures. To activate
> the privilege it must be added to the active set. Then the
> capabilities can be added to an executable file.
>
> At each step (login/activate privilege capability/adding capabilities
> to the file) is a security event, that can be logged and audited.
You can get the same damn thing with elfcap.
1. Require a capability bit to make setuid-root files
2. Only let that bit be active when running a special tool
3. Have the tool enforce whatever policy you like
>>> The filesystem features are neither horrible nor are exotic
>>> backup tools needed. I help oversee UNICOS systems using
>>> MLS + capabilities using cpio for backup, which does not need
>>> special privileges to perform backups. If a root system has
>>> to be restored, it is done in single user mode, THEN the
>>> specified privileges (capabilities) are assigned to the
>>> relevent images.
>>
>> There you go, using an exotic backup tool. (not cpio, I mean the
>> tool used to assign privileges after cpio is done)
>
> Its not a backup tool. It is the same one used to assign
> capabilities to files in the first place.
Ugh... say you have a Beowulf-style cluster with 1000 nodes,
and you want to install the software. You intend to sit at
the console of each one and type in lots of commands?
>> With elfcap, inability to create setuid files implies inability
>> to assign capabilities. Even better, inability to create files
>> owned by root also implies inability to assign capabilities.
>> An attacker would have to do both, to the same file, at the same time.
>> If random users can do this, you have a problem even without elfcap.
>
> No it doesn't. The user can still set the bits in the executable.
Those are meaningless bits.
>>> Any use of a capability is a security event.
>>> Any attempt to use a capability that is not authorized is a
>>> security violation.
>>> The level audit logging is up to the facility.
>>
>> So what? Elfcap can handle this perfectly well. Like the other
>> two proposed systems, elfcap is a kernel feature. You can trust
>> that the logging will happen.
>
> It cannot detect the unauthorized addition of capabilities to an
> executable.
1. how could this happen?
2. it is little trouble to scan a few setuid files in detail
>> Security is reduced because existing admin scripts will not find
>> the XFS or ext2 extensions. Capability bits have enough trouble
>> with compatibility just by design; filesystem hacks make them worse.
>
> They arn't extensions. The bits have been there from the
> first time I looked at the internals of the file system.
I don't see them in "struct stat" and I can't find a way to
make the find command list anything odd. Anyway, neither would
even help with all the old admin scripts.
>> Problem: due to compatibility problems and management complaints,
>> a site decides to go back to the old way... but the filesystem is
>> now unreadable by the old kernel.
>
> 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.
>>> Any filesystem should work with root privilege (well... excluding dosfs).
>>
>> The in-memory system would even work with dosfs.
>
> I partially agree since I realize you mean the capability only system.
> The reference to "root-privliege" not working with dosfs is because you
> cannot have a shadow password file stored on dosfs - owner/group/world all
> use the same protection bits and cannot prevent any user from reading the
> shadow file. Use of multiple dosfs file systems might work around that
> restriction, but it would break almost all of the password programs, the
> network daemons, ... That would call for a custom build of the utilities.
Heh... that is a whole different issue. Try strong encryption.
> 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 adavantage of the inode method is in the association of
> the capabilities with the inode that uses them. If the file is
> deleted, the capabilities are too. The in-memory implementation
> allows for the possiblitiy of the file being replaced without
> the list being updated. This possiblity is one that cannot be
> worked around.
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.
> Look at the RSBAC project for an active implementation of all of this
> http://www.rsbac.de/
That isn't exactly inode-based.
-
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