"Albert D. Cahalan" <acahalan@cs.uml.edu>:
> 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.
Not done deliberately. Done because it was hidden. For practical systems,
no one has the time needed to audit every file or executable.
> >> 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.
That depends on the use of the file. It may work perfectly in a
chroot environment.
> 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".
Any file COULD be a trojan. Those files with capabilities set via elfcap
capabilities are MORE LIKELY to be a trojan. This is an increase in risk.
Obviously you've never had to audit a system in detail. It takes a LONG time
to do.
> >>>>> 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.
1. UID 0 should have no special privileges.
2. client apps may NOT pass credentials over a socket. No security whatsoever
there.
> >>>> 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
You weren't paying attention - there are no privileges as root.
setuid is only a capability. It allows switching uid's, nothing else.
> >>> 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?
No more than is done now during the installation.
> >> 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.
NO - they are a major POTENTIAL trap.
> >>> 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?
a user sets the capabilities in the elf executable. It doesn't matter
even if the executable mode is clear. The file is a problem. The risk
order would be (from low to high):
1. file
2. executable, or file with elfcap set (but not executable or setuid)
3. executable with elfcap set (but not setuid)
> 2. it is little trouble to scan a few setuid files in detail
you have to scan EVERY file and look for capabilities. The "setuid" file
is just the one that is active.
> >> 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.
Not the in memory struct, look at the disk resident bits. There are a
LOT of definitions there, including an auxilary inode number, ACL inode
entry,.
Even if it does call for a new/different file system, I wouldn't have a
problem with that. Use XFS instead.
> >> 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.
1. Any encrypted file can be broken (look at the TWINKLE proposal for high
speed factoring... the analysis appears to indicate that 128 bit keys
could be broken in a few hours)
2. the kernel would have to be holding the decryption key to decrypt it any
time the user wanted to change his password.
3. If you were assuming strong encryption on only the password, the
shadow file contains other sensitive information that should not be
visible.
> > 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.
True. I would prefer to be able to use the file system, which is already
protected once mounted.
> > 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.
No it doesn't - if the user has write access to the file then the contents
can be replaced. This is only prevented by the immutable attribute, which
is an inode "capability".
> > Look at the RSBAC project for an active implementation of all of this
> > http://www.rsbac.de/
>
> That isn't exactly inode-based.
I know that - it is an in-memory implementation using a file. It IS the
most complete implementation of a secure Linux system that I know of.
-------------------------------------------------------------------------
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 : Thu Jun 15 2000 - 21:00:35 EST