lkml.org 
[lkml]   [1998]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [patch 2.1.97] more capabilities support
    Date
    >>>> I believe we were discussing POSIX capabilities, not pure capabilities.
    >>>>
    >>>> I'll mail you about the pure capabilities later, but it appears that
    >>>> they are fairly useless outside of an environment like EROS:
    >>>> persistent system image, long-lived processes, NO FILESYSTEM, and
    >>>> every scrap of data is an object associated with some code.
    >>>
    >>> You haven't even looked at the design:)
    >>
    >> I kept asking you for one (in private email)... where is it?
    >
    > It's on the URL that I gave you and that you haven't even looked at

    I did not get any URL from you. I found the EROS web page myself,
    using the altavista.digital.com search engine. I also sent mail
    to the author.

    > (it's obvious because the page also includes notes on design
    > of a UNIX compatible system on top of pure capabilities).

    I'm going to substitute the EROS web page for the one you claim
    to have told me about: http://www.cis.upenn.edu/~eros/

    The EROS web page documents such a thing. It is a hack, and does
    not claim to integrate well with the "native" EROS software.
    You can emulate Unix on the MacOS too, but it doesn't fit right.

    Look, this is seriously alien. It would require a massive kernel
    rewrite, most likely with a microkernel design.

    >> It is interesting, and perhaps it is useful for some people.
    >> It is _not_ anything like Linux and can't support basic POSIX
    >> features very well. For example, you have to give up much of
    >> the security and run Unix emulation if you want a real filesystem.
    >> (yeah, no kidding: we get rid of open(2) and just pass fd's around)
    >
    > You talk about the filesystem as something that is fundamentally
    > a good thing (which it is not).

    Users expect it. Programmers expect it. Admins expect it.
    Other systems expect and provide it over NFS, SMB, and NCP.

    > It's just the current way of ensuring the persistency of data because
    > we're not able to achieve general persistency. A filesystem can
    > _easily_ be emulated if you have general persistency of objects

    So we always run in emulation... that won't do. We need to add
    security features that can work well with normal unix software.

    Think in terms of _extending_ the current system in compatible ways.
    Linux is a real-life OS, not a theoretical OS. There are standards
    that we try to comply with, such as Version 2 of the Single Unix
    Specification and various BSDisms.

    We can have a non-unix environment if there is no other way.
    For example, the RT-Linux API is not quite standard. It is not
    a problem though, because nobody tries to run the whole system
    in that environment. Security needs to be everywhere, not just
    for people that can live without unix software.

    I know you may be able to give each user their own "unix" to
    run in, but that is total isolation. Unix is multi-user.

    > you don't _want_ to take a step back and implement a subsystem that
    > has been the source of numerous security holes. Also, the filesystem
    > wastes a lot of the disk's potential performance.

    I don't believe this is negotiable. We can't have a barrier between
    the POSIX apps and the new apps -- it would be worse than Windows NT.

    > If you on the other hand do periodic snapshots of the system memory,
    > the writes to the disk can be done very fast (close to the maximum),
    > because you don't have to seek all the time but you simply dump the
    > whole memory as a one block write (or several consecutive ones).

    Yes. For people that can spare the swap space, it would be good to
    do such a thing _in_ _addition_ to the normal filesystem.

    > As for open(), you really picked a stupid example to show 'disadvantages
    > of pure capabilities'. Wouldn't it be an _optimization_ if you could get
    > rid of a neccessary step of opening a file and just access it directly?

    We can do that already, by passing file descriptors. It isn't often
    done though, because open() is fairly cheap and portable. We don't
    have a persistant system image and _can't_ with the way people like
    to upgrade the kernel. If you can solve the "upgrade kernel w/o reboot"
    problem then you have solved the persistance problem: they are the same.
    So far, nobody is close to solving that problem for Linux.

    >>>> I hope everyone has seen this by now:
    >>>> http://agn-www.informatik.uni-hamburg.de/people/1ott/rsbac/index.htm
    >>>
    >>> Yes, we have seen it, but the thesys is in German
    >>
    >> I thought people were complaining about the web page in German.
    >> I just assumed everybody would grab to code itself, not the thesis.
    >
    > Code is just the implementation of the concept. If the concept is
    > flawed, don't you think that the implementation will be fundamentally
    > flawed too?

    You can see the concept by looking at the code. Somebody else just
    pointed out that it would be easy to add auditing to the code.
    We need that anyway, just to reach C2 AFAIK.

    > I appologize if this mail may seem as a bit of flaming, but it really
    > annoys me if people put down designs without at least _trying_ to
    > understand them.

    After a long private discussion with you, a web search for EROS
    and KeyKOS, an email to the EROS author... you should not claim
    that I have failed to consider your ideas. I put many hours of
    research and thought into the matter.

    > I would be very happy if someone could provide me with real
    > arguments, why capability lists and ACLs are better than pure
    > capabilities (I assume Linux kernel developers think so because
    > it seems that they prefer those designs).

    I already did, in private email.

    > PS: There's an intresting saying that I saw at the bottom of some
    > page about pure capabilities: Let's argue to learn, not to win..

    Sure, I agree. Please convince me I'm wrong. I really do try to see
    this your way, as you can see by the amount of time I put into
    learning about EROS and your ideas for Linux.

    Have you ever used such a system for real work? If so, describe
    what it was like compiling and using standard unix software like
    emacs, gcc, tex, bash, and ghostscript. That is, what advantages
    did you get while running unix tools? How well did NFS exports work?

    Consider the following real-world compromise:

    We can implement pure capabilities like Data General does for their
    B2 certified DG-UX. They are an "additional access control mechanism"
    as defined by Unix98: they can only restrict access. If you want to
    use them exclusively, you can "chmod 777" every file after you add
    the capability information. This is compatible, safe, and won't
    violate the standards.

    Standards compliance note: "chmod 000 foo" absolutely must make the
    file inaccessable. (must "disable alternate access control")
    The opposite need not be true: "chmod 777 foo" might not give
    everyone access to the file. (can keep "additional" access control)

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

    \
     
     \ /
      Last update: 2005-03-22 13:42    [W:0.029 / U:0.640 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site