chroot email + browser ??? - Security

This is a discussion on chroot email + browser ??? - Security ; A lot of lore says that if a Linux user is attacked via web, email, or a virus, that the system itself won't suffer since the user only has permissions to mess up their own files. Certainly that's true to ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: chroot email + browser ???

  1. chroot email + browser ???

    A lot of lore says that if a Linux user is attacked via web,
    email, or a virus, that the system itself won't suffer since the
    user only has permissions to mess up their own files. Certainly
    that's true to a point. My question regards what to do about
    attacks on an individual user. I've been pondering the idea of
    creating a separate user account for my email and web activities,
    running those clients as that user, and the rest of my activities
    as a standard user. The standard user would have permissions to
    do as they pleased with the internet user's files, but not the
    other way around. Maybe there's a good way to chroot an email
    client or a web client. My goal is to make email and browsing
    safer. I don't chat or instant message, maybe some folks would
    have interest in making those activities safer. What are your
    thoughts on this?

    Thanks....

    --
    PLEASE post a SUMMARY of the answer(s) to your question(s)!
    Show Windows & Gates to the exit door.
    Unless otherwise noted, the statements herein reflect my personal
    opinions and not those of any organization with which I may be affiliated.

  2. Re: chroot email + browser ???

    On Fri, 24 Feb 2006 16:17:09 +0000, Kevin the Drummer wrote:

    > [...] My question regards what to do about attacks on an individual
    > user. I've been pondering the idea of creating a separate user account
    > for my email and web activities, running those clients as that user, and
    > the rest of my activities as a standard user. The standard user would
    > have permissions to do as they pleased with the internet user's files,
    > but not the other way around.


    I've been setting stuff up like that for years, for CLI/TUI applications
    it's a simple matter of adding the user, to /etc/suauth a line such as:

    # Allow 'menno' access to .fetchmailrc and stuff
    pine:menno:NOPASS

    And an alias in ~/.profile and ~/.bashrc of user menno (which i may have
    setup to autologin also (via /etc/inittab , or [XKG]DM)).

    For X applications i use the .Xauthority file although one might (almost)
    as well add a line to maybe ~/.xinitrc that does a 'xhost +local:'
    provided the machine doesn't provide shell access occasionally. Here is
    some what of an attempt at a howto - for FireFox under FVWM on Slackware:
    http://groups.google.nl/group/alt.os...6ddf2b4f6c1828

    > Maybe there's a good way to chroot an email client or a web client.


    First thing that comes to mind would be to add a * before the shell in
    /etc/passwd (that should chroot to wherever the $HOME field points.)

    > My goal is to make email and browsing safer.


    I don't think chrooting is going to add much (if any) to that end,
    provided user/group protection bits are setup properly on your system...
    Specifically you may want to look group/other bits on suid binaries:
    http://groups.google.nl/group/alt.os...64ccdbcf16ebfe

    > I don't chat or instant message, maybe some folks would have interest in
    > making those activities safer. What are your thoughts on this?


    The network client applications under seperate user accounts, seems like a
    good idee to me (obviosly), however chroot might well be more trouble then
    it's worth IME. Recovering from a messed-up 'firefox' account, is just
    emptying the home-dir and restore the bookmarks file from backup.

    Note also with X apps an atacker has pretty much full-control over your
    display (and may even be able to spy the keyboard) shoud they hack into
    an abitrary application, so this doesn't effectively eliminate (browser)
    session hijacking, or even key/pasphrase logging should you use an X-term
    for ssh on the same desktop (another X-server on tty8 for instance would
    be better still.) But such an attack may not be very easy to automate.

    HTH.

    --
    -Menno.


  3. Re: chroot email + browser ???

    nobody@tek.com (Kevin the Drummer) (06-02-24 16:17:09):

    > A lot of lore says that if a Linux user is attacked via web,
    > email, or a virus, that the system itself won't suffer since the
    > user only has permissions to mess up their own files. Certainly
    > that's true to a point. My question regards what to do about
    > attacks on an individual user. I've been pondering the idea of
    > creating a separate user account for my email and web activities,
    > running those clients as that user, and the rest of my activities
    > as a standard user. The standard user would have permissions to
    > do as they pleased with the internet user's files, but not the
    > other way around. Maybe there's a good way to chroot an email
    > client or a web client. My goal is to make email and browsing
    > safer. I don't chat or instant message, maybe some folks would
    > have interest in making those activities safer. What are your
    > thoughts on this?


    You could well create a user for every application you use. This is a
    bit exaggerated, but if you're that paranoid (like me), then that's the
    easiest solution. Then allow your main user to use sudo without a
    password. Remember to still give the different accounts different
    passwords, otherwise you have no gain in security. Don't worry about
    that passwordless sudo. An attacker would get access to that
    functionality only, if he gets to your main account. This also means
    that you have to protect your main account with a strong password (for
    example).

    You should also use something like grsecurity [1]. The secondary users
    (e.g. for email) should be created in a special group, for which you
    activate 'trusted path execution' (a grsecurity functionality). If an
    attacker compromises an account, he has no way to fool you by modifying
    PATH and substituting your, say, email program by a trojan wrapper. TPE
    means that users in this special group are only allowed to run programs
    in 'well known' directories (like /bin and /usr/bin).

    For your main account you'll want to consider alternative authentication
    schemes (i.e. not passwords). You can do that via PAM modules. I
    haven't done that myself yet, though, but I'm going to go for it.

    Regards.


    ---

    [1] http://www.grsecurity.net/

  4. Re: chroot email + browser ???

    On Sun, 26 Feb 2006 04:20:17 +0100, Ertugrul Soeylemez wrote:
    > nobody@tek.com (Kevin the Drummer) (06-02-24 16:17:09):


    [ Mail and Web apps under different users. ]

    > Then allow your main user to use sudo without a password. Remember to
    > still give the different accounts different passwords, otherwise you
    > have no gain in security.


    No. The useradd command defaults to something like * or !! in the password
    field of the /etc/shadow file (if it doesn't: change it to that by hand)
    which *disables* password login to that account altogether, you can still
    'su' to it though. But if you use 'sudo' anyways you can do better still
    and set the shell of the user to /bin/false (use like 'sudo -s -u '
    for testing wat the user can do - if needed.)

    > Don't worry about that passwordless sudo. An attacker would get access
    > to that functionality only, if he gets to your main account.


    Better make sure of that, as there have been some exploits that may
    escalate privileage via sudo in case someone can execute a script via it.

    menno@pc:~$ ls -l /usr/bin/sudo
    -rwxr-x--- 1 root sudo 92928 2005-06-22 06:50 /usr/bin/sudo*

    And add your main account to the sudo group ofcource.

    --
    -Menno.


  5. Re: chroot email + browser ???

    Menno Duursma (06-02-26 09:13:38):

    > > nobody@tek.com (Kevin the Drummer) (06-02-24 16:17:09):

    >
    > [ Mail and Web apps under different users. ]


    That's a verbatim copy of the email address from the "From" header in
    the OP's post. Not my fault.


    > > Then allow your main user to use sudo without a password. Remember
    > > to still give the different accounts different passwords, otherwise
    > > you have no gain in security.

    >
    > No. The useradd command defaults to something like * or !! in the
    > password field of the /etc/shadow file (if it doesn't: change it to
    > that by hand) which *disables* password login to that account
    > altogether, you can still 'su' to it though. But if you use 'sudo'
    > anyways you can do better still and set the shell of the user to
    > /bin/false (use like 'sudo -s -u ' for testing wat the user can
    > do - if needed.)


    On my box, sudo denies access to accounts without a password or valid
    shell. I'd set some random password for this kind of account.


    Regards.

+ Reply to Thread