--------- Received message begins Here ---------
>
> Jesse I Pollard, II writes:
> > "Albert D. Cahalan" <acahalan@cs.uml.edu>:
> >> Jesse I Pollard, II writes:
> >>> Pavel Machek <pavel@suse.cz>:
>
> >>>> Fine. You have no problems with elfcap, then. Noone has setuid 0 bit,
> >>>> you don't have to examine anything, elfcaps are nop.
> >>>
> >>> THEY ARE NOT - I may use them as root. Someone else may use them as root.
> >>
> >> Well, that would be pretty stupid of you, wouldn't it?
> >> Why in hell are you running trojan binaries as root?
> >> Why did you give this clueless "Someone else" admin power?
> >
> > Not my choice. I only audit the systems. The way elfcap is
> > implemented means I cannot audit the executables.
> ...
> > If MAC override is in some piece of junk like elfcap then I have
> > no audit control to determine if it is there.
>
> 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.
> 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.
> >>> 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). But sendmail works properly (barring
bugs of course) when used in a totally unprivileged manner.
> >> 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.
>
/> See, you had made some claims about suddenly having privileged
> executables on the system. That just won't happen, except due
> to errors that affect both elfcap and your preferred design.
It is very difficult to add it accidentally.
> >>>>> of binary only installation software is very large, since many vendors do
> >>>>> not want the installation procedure modified. Since I can't look at the
> >>>>> binaries before installation, I can only look at them afterward. elfcap
> >>>>> makes it necessary to examin every file (executable or not) to search for
> >>>>> trojan horses with improper capability assignments.
> >>>>
> >>>> No. Just search executable being setuid 0 for trojan horses. Elfcap is
> >>>> nop for binaries not being setuid 0. Take a look at code.
> >>>
> >>> did. and I repeat:
> >>>
> >>> NO ELFCAP. not secure, not reliable, not auditable.
> >>
> >> Oh bullshit. You've not proven any of that. I can well imagine
> >> that one might think elfcap is ugly, but it gets the job done.
> >> It is just horrible to require exotic filesystem features and
> >> exotic backup tools when they shouldn't be needed at all.
> >
> > It is only reasonable as a prototype, not production.
> >
> > 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.
>
> If you actually LIKE doing that, surely GNU cpio has an option
> to ignore setuid bits.
>
> > Users should not be able to create setuid files. > > Users should not be able to assign capabilities.
>
> No problem.
>
> 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.
> > 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.
> >> As of now, the only other practical proposal was the one that
> >> involved registering privileged executables with the kernel,
> >> using an in-memory set of capabilities and an immutable bit.
> >
> > That is very ugly, but it is secure.
>
> It is the least ugly and the most secure.
>
> > And the proposals to use ext2 or
> > XFS to store capabilities in the inode are practical, and secure.
>
> 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.
> >> It is about time that you admit elfcap gets the job done.
> >
> > Again, it is only reasonable as a prototype. It is not reliable, nor
> > fully enforcable as it stands. It is no better than setuid, and it
> > diffuses the ability to audit setuid since the actual priviliges are
> > not apparent. That makes it difficult/impossible to have a verifiable
> > audit.
>
> Filesystem hacks are least reliable, least enforcable,
> and least apparent. Only the in-memory system can beat elfcap.
I would change the order between the first two, but I agree that the
in-memory system can beat elfcap.
> > I want BETTER. There are standards (even if draft) that do define a better
> > way. Ext2 already has the storage assigned. XFS already has the storage
> > assigned. All that is left is completing and validating the implementation.
> > That is in the works by at least two different approaches. Which will be the
> > better is still open (assuming only one, both may be desirable).
> >
> > I see no problem with a requirement that the root filesystem be one of
> > these when the system is going to be used for a capability-only privilege
> > operation.
>
> 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
system to another. The foreign disk could have file with capabilities
set that could be imported. This is where labling of the disk works in.
(file system disk labels not used either).
> Problem: somebody wants to run a secure system from a standard
> CD-ROM filesystem.
Can be done - just put a ext2 or XFS filesystem on it. In fact, when I
last looked at trusted IRIX (a while ago) that was exactly what it looked
like they did.
> Problem: for an NFS-root system, one would very much want to avoid
> letting users get raw network access... NFS is bad enough, and you
> would not let NFS-root users try to defend themselves.
Now you have a point. This is not intended for NFS, since NFS doesn't
carry the proper filesystem. The server can use capabilities, the client
root system cannot. In fact, no (current) network file system will work.
There are some that can, but they are propriatary (Cray NFS can, also works
with multi-level filesystems).
None of the current capability entries support control of the network (yet).
That calls for IPSec, and additional capability bits.
> > 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.
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.
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.
Look at the RSBAC project for an active implementation of all of this
http://www.rsbac.de/
-------------------------------------------------------------------------
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:33 EST