Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: Something strange with apparmor

  1. #1
    Join Date
    May 2011
    Beans
    42
    Distro
    Ubuntu 10.04 Lucid Lynx

    Red face Something strange with apparmor (update: apparmor is broken!)

    Either it's me doing something seriously wrong, or something is seriously wrong with apparmor!

    I've confined a program with apparmor to restrict its write access to the file system.

    But everywhere the confined program has read access only, it can also delete any file and folder trough its file browser if the owner of the program also owns the files and folders in question. I thought it had to have write access in the profile to do that. How do I stop the application from deleting files and folders with apparmor?

    The profile does work somehow, because the program can't manipulate or write to files and folders where it only has read access. But it can delete all of them without any problem.

    Please help me out here! :-/
    Last edited by desire.linux; May 9th, 2012 at 08:08 PM.

  2. #2
    Join Date
    May 2011
    Beans
    42
    Distro
    Ubuntu 10.04 Lucid Lynx

    Exclamation Re: Something strange with apparmor (update: apparmor is broken!)

    I got help from a security guru to look at my apparmor problem, and his concision is simple: apparmor is broken!

    It works only partially on some applications, and should not be trusted AT ALL to secure a system!

    We tested the image viewer Gwenview that's strictly confined with apparmor. All executables in the profile are inherited, so they should follow the apparmor profile for Gwenview. Hence Gwenview can't start external none confined programs to mess around on the filesystem.

    Gwenview, being strictly confined with apparmor, can create files and folders, and delete files and folders, at the areas of the file system where it does not have write access, only read access. This happens when the owner of the folders and files is the same as the owner who runs Gwenview. Hence apparmor simply skips its own access control for such actions and jumps directly to traditional DAC. It simply doesn't work!

    Though it does manage to deny modifications of existing files, like overwrite, so it works partially. And it seems to stop execution unless you allow it to. But with such a major security hole in the apparmor framework in the first place, it's impossible to know where it might brake at other places.

    This is probably a huge security hole in the framework that hopefully will be fixed soon for those who still trust and rely on apparmor.

    My friend told me that this is one of the reaons why apparmor isn't very popular among other Linux distros and was rejected by Debian. It's utterly bad and flawed, and he urges me to use tomoyo or selinux instead. Apparmor is a great idea, because it's so simple and user friendly, but unfortunately an idea is all it is.

    So now you're warned! And end of story.

    For those who are interested, Fedora uses selinux by default and it has a GUI to make things simpler. I know that Ubuntu wants to keep things simple, but on the cost of our security? I'll rather use more time and patience on a more complex system, like Fedora, and obviously stay a lot safer.

  3. #3
    Join Date
    Oct 2009
    Beans
    Hidden!
    Distro
    Ubuntu 16.04 Xenial Xerus

    Re: Something strange with apparmor (update: apparmor is broken!)

    It isn't a problem with apparmor, it is the way Linux file permissions work. The owner of a file can delete files even if they do not have write access to them.
    Come to #ubuntuforums! We have cookies! | Basic Ubuntu Security Guide

    Tomorrow's an illusion and yesterday's a dream, today is a solution...

  4. #4
    Join Date
    Apr 2006
    Location
    Montana
    Beans
    Hidden!
    Distro
    Kubuntu Development Release

    Re: Something strange with apparmor

    Actually these permissions are determined by the permissions on the DIRECTORY not the file.

    Code:
    # Notice how the directory test is "ro"
    bodhi@ufbt:~/Documents$ ls -l | grep test
    dr-xr-x--- 2 bodhi bodhi 4096 2012-05-09 15:29 test
    
    bodhi@ufbt:~/Documents$ ls -l test
    -rw-rw-r-- 1 bodhi bodhi 0 2012-05-09 15:29 file
    
    # But I can read and write to the file "file"
    bodhi@ufbt:~/Documents$ echo "can write" >> test/file
    bodhi@ufbt:~/Documents$ cat test/file
    can write
    
    # But I can not delete it
    bodhi@ufbt:~/Documents$ rm test/file
    rm: remove regular file `test/file'? y
    rm: cannot remove `test/file': Permission denied
    See http://www.tuxfiles.org/linuxhelp/filepermissions.html

    Read permission. On a regular file, the read permission bit means the file can be opened and read. On a directory, the read permission means you can list the contents of the directory.

    Write permission. On a regular file, this means you can modify the file, aka write new data to the file. In the case of a directory, the write permission means you can add, remove, and rename files in the directory. This means that if a file has the write permission bit, you are allowed to modify the file's contents, but you're allowed to rename or delete the file only if the permissions of the file's directory allow you to do so.

    Execute permission. In the case of a regular file, this means you can execute the file as a program or a shell script. On a directory, the execute permission (also called the "search bit") allows you to access files in the directory and enter it, with the cd command, for example. However, note that although the execute bit lets you enter the directory, you're not allowed to list its contents, unless you also have the read permissions to that directory.
    Last edited by bodhi.zazen; May 9th, 2012 at 10:40 PM.
    There are two mistakes one can make along the road to truth...not going all the way, and not starting.
    --Prince Gautama Siddharta

    #ubuntuforums web interface

  5. #5
    Join Date
    Apr 2006
    Location
    Montana
    Beans
    Hidden!
    Distro
    Kubuntu Development Release

    Re: Something strange with apparmor (update: apparmor is broken!)

    Quote Originally Posted by desire.linux View Post
    I got help from a security guru to look at my apparmor problem, and his concision is simple: apparmor is broken!
    Sounds as if your security guru does not understand Linux permissions.

    In addition, if you need help with apparmor, you will need to post your apparmor profile for the program you are trying to confine. I can not tell from your original post if you are using one or two applications. You do understand each application needs it's own profile.
    Last edited by bodhi.zazen; May 9th, 2012 at 10:48 PM.
    There are two mistakes one can make along the road to truth...not going all the way, and not starting.
    --Prince Gautama Siddharta

    #ubuntuforums web interface

  6. #6
    Join Date
    Mar 2011
    Beans
    680

    Re: Something strange with apparmor (update: apparmor is broken!)

    I get that this isn't a flaw or that dangerous, after all deleting a file it owns isn't a biggie, but how would one stop it from doing this? I would have thought denying write access would do this.

  7. #7
    Join Date
    Nov 2009
    Beans
    919
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: Something strange with apparmor (update: apparmor is broken!)

    Quote Originally Posted by Hungry Man View Post
    I get that this isn't a flaw or that dangerous, after all deleting a file it owns isn't a biggie, but how would one stop it from doing this? I would have thought denying write access would do this.
    I think you'd stop it by denying write access to the directory. Think of the files as the contents of the directory in the way that words are the contents of a file (kind of). You would need to deny write permissions to the directory to prevent addition/deletion of files, and also deny write access to the file in order to prevent modification of it.

  8. #8
    Join Date
    Apr 2006
    Location
    Montana
    Beans
    Hidden!
    Distro
    Kubuntu Development Release

    Re: Something strange with apparmor (update: apparmor is broken!)

    Quote Originally Posted by Hungry Man View Post
    I get that this isn't a flaw or that dangerous, after all deleting a file it owns isn't a biggie, but how would one stop it from doing this? I would have thought denying write access would do this.
    It is not a flaw or dangerous, it is users not understanding permissions and/or apparmor.

    You would stop it by learning permissions and/or apparmor and configuring them properly.

    I think you should re-read my first post, I demonstrated how to configure rw access to a file, without permission to delete the file, with permissions.

    With apparmor you would use a rather then w
    There are two mistakes one can make along the road to truth...not going all the way, and not starting.
    --Prince Gautama Siddharta

    #ubuntuforums web interface

  9. #9
    Join Date
    Mar 2011
    Beans
    680

    Re: Something strange with apparmor (update: apparmor is broken!)

    I'm not saying it's a flaw or dangerous. If a program creates the file it can then delete it, yes? That's the perceived issue, right?

    And thanks I'll read it.

  10. #10
    Join Date
    Apr 2006
    Location
    Montana
    Beans
    Hidden!
    Distro
    Kubuntu Development Release

    Re: Something strange with apparmor (update: apparmor is broken!)

    Quote Originally Posted by Hungry Man View Post
    I'm not saying it's a flaw or dangerous. If a program creates the file it can then delete it, yes? That's the perceived issue, right?

    And thanks I'll read it.
    I am not really sure what you are asking here. Are you asking about permissions ? Apparmor ? deleting files ? which files ?

    Permissions are your first line of defense, period. If standard (DAC) permissions deny access, apparmor policy is never consulted.

    AppArmor provides an additional permission check to DAC. DAC is always checked first such that if it does not allow access, the AppArmor permission checks will not be performed.
    http://wiki.apparmor.net/index.php/Q...iffer_from_DAC

    Apparmor file permissions are covered in the man page:

    http://manpages.ubuntu.com/manpages/...armor.d.5.html

    Access Modes Details
    r - Read mode
    Allows the program to have read access to the file or directory
    listing. Read access is required for shell scripts and other
    interpreted content.

    w - Write mode
    Allows the program to have write access to the file. Files and
    directories must have this permission if they are to be unlinked
    (removed.) Write mode is not required on a directory to rename or
    create files within the directory.

    This mode conflicts with append mode.

    a - Append mode
    Allows the program to have a limited appending only write access to
    the file. Append mode will prevent an application from opening the
    file for write unless it passes the O_APPEND parameter flag on
    open.

    The mode conflicts with Write mode.
    With those references as background, the answer to the OP question is to use (DAC) permissions to configure permissions on directories and files appropriately, as I demonstrated in my post. With proper DAC permissions, permission is denied and the apparmor profile never comes into play.
    There are two mistakes one can make along the road to truth...not going all the way, and not starting.
    --Prince Gautama Siddharta

    #ubuntuforums web interface

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •