> -----Original Message-----
> From: Albert D. Cahalan [mailto:acahalan@cs.uml.edu]
> Sent: Wednesday, June 14, 2000 8:05 PM
> To: Jesse Pollard
> Cc: acahalan@cs.uml.edu; Jesse Pollard; pavel@suse.cz;
> pavel-velo@bug.ucw.cz; Joseph Gooch; linux-kernel@vger.rutgers.edu
> Subject: Re: Ke: Process Capabilities on 2.2.16, Sendmail problem
> revisited
>
>
> 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.
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.
If i'm going to the trouble of searching my drive i want to see the
capabilities. This involves 2 steps with elfcap (scan for setuid root, read
and parse header) and only one with inode based. Memory based is O(1).
We'll just have to agree to disagree in this category, it's a judgement
call.
> 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. Other than that, we're at an opinion
again. Memory versus file versus fs.
> >> 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".
We'd never be that dumb, but people who don't know better might. We're
playing devil's advocate here. Look at it this way, I've never heard of
someone accidentally chattr'ing a file immutable, but I've heard many
stories of corrupted or deleted files.
> >>>>> 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.
Once one or all of the three methods are available the securelevel can
change and UID is no longer god. No argument here.
> >>>> 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
And the same thing with in-memory. They can all do similar if not the same
things. No argument here.
> >>> 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?
Scripts run quickly.
Backup solutions are backup solutions, most of them ARE hodge-podge. You
can live with it or buy ArcserveIT for Linux :) Of course that probably
doesn't support caps in any form either.
> >> 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.
Trojans happen all the time because people aren't aware of certain events.
Changing the bits around here is no different.
> >>> 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
We'll have to agree to disagree here.
> >> 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.
I know space is there, but I can't be any more specific. Linux-ACLs did it
somehow.
> >> 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.
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."
> >>> 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.
Why would anyone run a privileged exec off of a dosfs. That's just dumb. :)
> > 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. I never was a big
fan of securelevels and that's very close to it.
> > 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.
This is a lot of overhead for something easily put in the filesystem.
All I can say is, we'll have to agree to disagree. Each of the models have
their strengths and weaknesses. That's why I think they should all be
options. I'm sure the 3 of us will use different options, that's the power
of Linux. I grow weary of this favorites match and none of us are going to
convince each other anyway.
Joe
-
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