[03:10] Has anyone run into problems starting AppArmor on Xenial when there are a large number of profiles to load? It's been starting for ~2 hours, seems to be writing to /etc/apparmor.d/cache/usr.sbin.apache2. Kernel: 4.4.0-57-generic, Release: 16.04.1 LTS === cmh__ is now known as cmh_ [03:12] cmh_: hey - that's not a known issue [03:12] cmh_: could you file a bug report? [03:13] cmh_: what version of the apparmor package do you have installed? [03:16] tyhicks: apparmor 2.10.95-0ubuntu2.5 [03:20] cmh_: does `sudo apparmor_parser -Q /etc/apparmor.d/usr.sbin.apache2` complete? (shouldn't take more than a few seconds at the most) === rxc is now known as Guest8537 [03:36] tyhicks: adding the -v flag shows 'Addition succeeded for "Profile Name"' for the profiles. [03:37] On another server (same Kernel/Release) it shows "Cached load succeeded for "/etc/apparmor.d/cache/usr.sbin.apache2"." ... [03:37] hm === giraffe is now known as Guest35314 === PaulePan1er is now known as PaulePanter === lordieva- is now known as lordievader === lordievader is now known as Guest10438 [08:50] hello all [08:51] when is the next Horizon Newton package refresh gonna happen ? I am interested in this patch https://review.openstack.org/#/c/403160/ [08:52] also it is not clear to me [08:52] when I do [08:52] debcheckout --git-track='*' horizon [08:52] and then I checkout stable/newton [08:52] it looks from the changelog that I am patching the yakkety tree [08:52] there are different git repos for xenial and yakkety ? [08:53] I understand openstack releases are in different git branches, but what about the target distro ? === Guest10438 is now known as lordievader [08:56] Good morning. === thib_ is now known as thib === T-Co_ is now known as T-Co [12:18] jamespage: coreycb any of you here ? [12:51] Anyone has experience building Openstack Newton deb packages for Ubuntu Xenial ? [13:04] zul, python-webob 1:1.6.2-2 synced from unstable [13:04] zioproto, o/ [13:05] coreycb: yippe skipee [13:05] coreycb: ill keep an eye on things [13:06] coreycb: hey there, did you read what I wrote earlier in the channel ? [13:06] debcheckout --git-track='*' horizon [13:06] zioproto, "I understand openstack releases are in different git branches, but what about the target distro ?" [13:06] yes [13:07] when I see the changelog [13:07] in the debian folder [13:07] I see yakkety lines [13:07] but I am building for xenial [13:07] zioproto, ok [13:07] zioproto, first, yes we only have branches per openstack release [13:07] okay. Now I am working on this repo git://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/horizon [13:08] I am in stable/newton [13:08] zioproto, xenial corresponds to mitaka. however it's also an LTS so we support the cloud archive for newton and ocata on xenial as well. [13:09] ok, so how do I make newton packages for xenial ? [13:09] I mean, I just write yakkety in the changelog ? [13:09] and then I build with sbuild-newton [13:10] sbuild-newton -d xenial-amd64 -A ../horizon_10.0.1-0ubuntu2.dsc [13:10] zioproto, that's correct [13:10] zioproto, s/yakkety/xenial-newton/ though [13:10] version number of the packages is the same across xenial and yakkety ? [13:11] wait I did not understand where I have to replace s/yakkety/xenial-newton/ [13:13] zioproto, version numbers of the packages are the same on xenial and newton for any package in the cloud archive, IF you have the newton cloud archive enabled on xenial [13:14] zioproto, here's the staging ppa for newton if you want to look through some packages: https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/newton-staging [13:14] deb http://ubuntu-cloud.archive.canonical.com/ubuntu xenial-updates/newton main" [13:15] I am using this one [13:16] zioproto, it's likely the same for the most part. packages get backported from yakkety to xenial-staging then promoted to xenial-proposed, then to xenial-updates [13:17] ok [13:17] we are changing the way we work here [13:18] before we had VMs pointing to a internal deb [13:18] repo [13:18] now we build docker images [13:18] so I am trying to install my deb packages [13:18] with dpkg [13:19] if I have three deb files to install [13:20] openstack-dashboard_10.0.1-0ubuntu2_all.deb openstack-dashboard-ubuntu-theme_10.0.1-0ubuntu2_all.deb python-django-horizon_10.0.1-0ubuntu2_all.deb [13:20] and they are not in a repo [13:20] they are just on my disk [13:20] how I install them correcttly [13:20] I always get deps problems [13:20] because I cant install just 1 at the time [13:24] zioproto: dpkg -i *.deb ? [13:24] ok I fixed it ! [13:24] maybe [13:25] looks like the problem [13:25] was that I was missing a apt-get update [13:25] in my script [13:25] so the repo was there [13:25] but not loaded [13:25] this xenial was still mitaka [13:26] openstack-dashboard-ubuntu-theme depends on openstack-dashboard (= 3:10.0.1-0ubuntu2); however: [13:26] Package openstack-dashboard is not configured yet. [13:28] I think the problem is with openstack-dashboard [13:28] that fails the configuration step [13:30] coreycb: I get this error, there is your name here :) https://bugs.launchpad.net/horizon/+bug/1643964 [13:30] Launchpad bug 1643964 in horizon (Ubuntu) "compressing static assets fails with xstatic-bootswatch 3.3.7.0" [Undecided,Fix released] [13:31] zioproto, are you using ocata? [13:32] no [13:32] I get the same error [13:32] trying to upgrade from [13:32] openstack-dashboard (3:10.0.1-0ubuntu1) [13:32] zioproto, did you build the package yourself? [13:32] to my package [13:32] yes [13:32] zioproto, did you create a new orig-xstatic.tar.gz? [13:32] I added a patch in debian/pachtes [13:32] yes I did [13:32] zioproto, if so,don't [13:33] ahhhhh [13:33] I should not ? [13:33] the procedure for horizon changed again ? [13:33] zioproto, no [13:34] zioproto, for ocata we'll regenerate orig-xstatic.tar.gz but for stable releases we don't, because it pulls down the latest xstatic libraries [13:34] zioproto, which is probably fine most of the time but it caused you to hit this bug which we've only fixed in ocata [13:37] I am trying now [13:37] gbp buildpackage -S -us -uc [13:37] and then build from the dsc file [13:37] without calling any xstatic stuff [13:39] build failed [13:39] because the xstatic files are missing [13:44] zioproto, use debuild with horizon [13:44] zioproto, also you need the xstatic-orig tar [13:44] zioproto, you can get it from the ppa above [13:46] so, I avoid to call ./debian/rules refresh-xstatic [13:48] http://ppa.launchpad.net/ubuntu-cloud-archive/newton-staging/ubuntu/pool/main/h/horizon/horizon_10.0.1.orig-xstatic.tar.gz [13:48] beisner-afk, when you get in can you promote python-webob to ocata-proposed? [13:49] zioproto, correct, just wget that [13:50] ok building at the moment [13:59] Build success! but I guess no one in the world can build horizon packages for xenial-newton without knowing this issue ! [14:00] ok but I still get this error [14:00] CommandError: An error occurred during rendering /usr/share/openstack-dashboard/openstack_dashboard/templates/horizon/_scripts.html: '\"../bower_components/respond/dest/respond.min.js\"' isn't accessible via COMPRESS_URL ('/horizon/static/') and can't be compressed [14:04] coreycb: yeah webob problems go away [14:32] coreycb: I was able to build the package and install it. But maybe the patch I was testing did not work [14:32] thanks for the support [14:34] zioproto, great, np === wwalker_ is now known as wwalker [16:12] I am wondering in linux/unix like os's what is the equivalent of local group/security policy gui in control panel for windows is for linux [16:13] or unix [16:14] ...I know unix/linux like os's have samba , winbind , openldap , pam and many other security alternatives that model active directory for if on a domain or local [16:15] What i am getting at is my main thing is can one in linux or unix os lock all administrators/ disable them [16:16] So one cann't sudo or su to a higher privilage level every again like one can do for windows os's [16:17] ...At that point the only way to get complete control back to your unix or linux distro would be to have some password reset program like chntpw is to windows sam analogy [16:18] ...I hope you understand what i am talking about and somebody that knows something about this elaborate on it [16:26] ...And what would happen if one booted from a live usb and deleted the shadow and password files from the etc folder. When the person booted up again I always wondered that but haven't got around to trying it or have a spare HDD right at the moment [16:29] gymdude: You're mixing several things there.. there are attibutes on the filesystem for ownership and modes [16:29] right so if you deleted the shadow and passwd files what would happen [16:30] gymdude: [16:30] gymdude: you wouldn't be able to login [16:30] https://www.cyberciti.biz/tips/recovering-deleted-etcshadow-password-file.html [16:30] the system would ask for maintenance root password [16:30] for login you don't have any users totally blank or not there and even if you did replace it with failed users you still have to get the ownership , modes , : : : parts of it correct to [16:31] dr4c4n: where would it get the password from if you've deleted /etc/{passwd,shadow} ? [16:31] you boot into single user mode, or init bash - there's no password [16:32] gymdude: not following there [16:33] basically PAM is the major system here that deals with the UID/GID mapping on the files [16:33] now PAM is a pluggable system, so there are many backend supported, like ldap, kerberos, sssd etc [16:33] wait if one rebooted there machine with out a shadow or password file what would happen would the linux os recreate just the basic root user with blank password , ask you to create a user , throw a error no user to login with ? [16:34] you need to go in single user and recreate the system for multi user [16:34] booting into init=/bin/bash *literally* drops you into bash shell [16:34] as root [16:35] I get the software command you gave me can be used to recreate the barebones shadow or password files but that won't help you with all the other users , file attributes ,owners you have destroyed you have to create them all by hand / remember them thats if your lucky [16:35] gymdude: that's what backups are for.. but I'm not following what you're specifically trying to do :) [16:36] But how can single user mode drop you into root you wiped root out because there is not users not even root because the password file is deleted [16:36] why not try it in a VM and find out [16:37] But sure if it some how by dropping to single user mode gives you a root privilage then yes you should beable to addgroup,user, chown ,...etc to get what you want to some extent back [16:37] that's what single user mode is, root [16:37] full privilege [16:38] there are different levels of init in unix, multi-user is one of them [16:38] So if any linux distro one can drop to single user mode then how is protect root password or other things doing anything [16:38] physical security, grub passwords, bios passwords etc etc [16:38] basically if someone can reboot your systems and has physical access, then the game can be over anyway [16:39] One could always drop to single user mode create a sudo user that has root privilage and do pretty much what they want [16:39] if you can drop to single user mode, games over already, why bother with a sudo user? [16:39] gymdude not if you restrain physical access to your machines [16:40] security is like an onion, many layers [16:40] gymdude security can never be absolute. let that percolate in your mind for a moment. [16:40] yup [16:40] security vs. usability -- pick your point [16:40] most secure system is one turned off buried beneath 6 feet of concrete [16:40] not very usable though [16:42] Ok well to get into single user mode you have to at least beable to customize the grub configuration files under boot which you cann't if you don't know the grub password or if you cann't privilage escalate to a user that can modify the /boot/grub files [16:42] gymdude there's also BIOS/EUFI password [16:43] and disk encryption, that requires unlocking [16:44] Ya but bios passwords in general aren't a good idea or work for large companies because then they have to remember tons of different bios passwords. If they had them all the same one person leaking it would eventually have a bunch of people knowing it [16:45] no, not true, there are solutions for MDM fleet management [16:45] And also the fact that if one forgot the bios password your screwed just basically smash your machine its done [16:45] no, not ture [16:45] *true - reset BIOS with a jumper [16:46] ....Usually companies are more concerned not with that but with securing there os they put on ... they already know that one with bios access could boot from a live distro and reformat or reinstall a different os's [16:48] Well if the mobo had bios jumpers then why care about setting the password all a person would have to do is reset with the jumps defeating the purpose of the password [16:48] yea, it's just to stop walkby or maybe a random thief with no knowledge [16:48] nothing in security is absolute [16:48] ... All i am saying is securing at the bios level is really not a good way unless its a one shot thing where no jumpers or reset can be done [16:49] again, it's an ensemble of security practices that help, not one specific thing [16:50] I get that one could make the motherboard to have a bios on a plug able bios pci like card so when the one shot is over they can just throw out the card and not the whole motherboard [16:51] well, your bios is in an EEPROM, so technically you can do that anyway [16:52] it's 'puggable' in that sense [16:52] But its integrated on the mobo so your really destroying the whole motherboard if you destroy the bios for it currently [16:54] That is a way for company computers to go thru less issue and still secure a bios password not having to worry about leaking because they can uses many different passwords and not worrying about forgetting one because they can just order another replacement bios for the problemed machine that one for gets the password from time to time [16:56] ...Because lets face it if the company computers cann't boot live alternative os because a bios password is set that cann't be figured out how could anybody modify anything on that computer ever [16:56] ...Never mind they could also take out the sata hard drive and replace it with there own as well [16:57] So in this respect bios securing isn't really worth it [16:58] suer [16:59] ...So thats why companies just secure there computers/laptops os by disabling all there local admin's when the person is not on the domain. Which would prevent them from having enough privilage to change there local policy settings [17:02] maybe in windows land [17:03] When we roll out laptops for users, they get admin privileges, but we also use dm-crypt [17:04] we trust the users (mainly devs) to manage themselves, sudo on their own systems is fine [17:04] we're just concerned about the data, hence encyption policies [17:06] Ya makes sense. Curious on linux is there away to do the equivalent of disabling all root privilaged accounts [17:06] Like in windows disabling all local admin accounts [17:06] for the sam file [17:07] it just be for the shadow or passwd /etc files i would imagine [17:08] on linux, the only user priveleged is root [17:08] not true there is different groups and privilage levels [17:08] associated with them [17:09] different levels of access, not full privilege. [17:09] * joelio has been doing this 20 years [17:10] ya but sudo users have full privilage as a root [17:10] no [17:10] sudo su - [17:10] yes, but sudo is very granular [17:10] you can choose a single command for example that a single user can run [17:10] look in /etc/sudoers [17:10] ya but by default its usually set up when you sudo you sudo to root privlage [17:10] no, that's just you assuming [17:10] sudo su - [17:11] puts you in full root as you're running su [17:11] su does to [17:11] su *sets* the super user, but you need to run sudo to escalate up [17:11] try and run su on a machine with no root password set [17:11] if i su i just become root i don't need sudo su [17:12] as I said, try that on ubuntu [17:12] there is no password set for root, that's why during install it asks you for a user [17:12] Default is no su, recommended is sudo -i for interactive, then exit when admin things are finished being done [17:12] no you can make it have a password, but default ubuntu has no password set [17:12] Hi. So normalling ones setting ethtool settings in the interfaces but I'm testing out libteamd/teaming interfaces. Is there any existing tools that will help manage just ethtool settings (vs me just applying them manually)? [17:13] super user is root right [17:13] interfaces file [17:13] ya su you need a password which fails if its not set up because of /etc file setup [17:13] greyolla: you can pass post-up commands in /etc/network/interfaces [17:14] that'll allow you to set at boot/interface bring up time [17:14] gymdude: UID0 is root :D [17:15] ya got you on that [17:15] why is it though one can do sudo apt-get and not sudo su first then apt-get install...etc [17:15] teamd requires that the interfaces be off before joining them to the team interfaces. Using the interfaces file / ifupdown seems to auto up them before applying the setting. Is there a way to specify not to bring up the interface but apply the changes still? [17:16] greyolla: yes use manual [17:16] I am wondering sudo executes commands under a different user but how do you know which user it is executing under [17:16] greyolla: iface eth0 inet manual ---- kinda thing [17:17] gymdude: sudo also logs auth escallation as well, when you go full root you lose some of that logging [17:17] I could go sudo -u user1 apt-get install ... which would execute that command under user1 [17:17] I can set it to manual but the settings do not apply until I add "auto eth0" which brings up the interface [17:18] i guess i am wondering what sudo defaults to if no switches are used is it root user [17:19] gymdude: just vanilla sudo {thing} will execute thing as uid 0 *but* you'll retain stuff like SUDO_USER env vars etc [17:19] so you know what user is executing even though they are doing something as root [17:20] what take precedence the env SUDO_USER being set to something other then root which would make you have to do sudo -u root to get the equivalent of sudo [17:21] I'm not following, sorry [17:21] If you set the SUDO_USER env to something does sudo uses that user by default other then 0 root user [17:21] by default when you do sudo [17:23] the env vars are just used in whatever application needs them, they don't override the calling user from an ACL perspective [17:23] they're just handlers so an app knows who's instantiated it [17:24] yes and that application could be for sudo itself [17:26] so you can only have one and only one root account and by disabling this would be like the equivalent of disabling all local administrators is that correct [17:26] so one only needs to disable root user [17:27] no [17:27] you need uid 0 [17:27] there is (generally) only one root user, the others all escalate their CAPS depending on what's set [17:27] But if there is no root how can there be any uid 0 or person using it [17:28] uid0 == root [17:28] I'm going home now anyway, enjoy :) [17:28] right [17:28] gymdude: there has to be root. if you remove (or change) the definition of root in /etc/passwd your entire system will break [17:29] So then how does one prevent all users from privilage escalation to uid0 [17:29] gymdude: in any case, uid 0 is what's special. uid 0 is the superuser regardless of what name /etc/passwd assigns it [17:29] gymdude: they're not in the sudo group, or not set in sudoers [17:29] by default [17:29] you have to add them to sudo (wheel) group or add them in sudoers [17:29] when you install ubuntu the user is added with sudo group membership automatically [17:30] The default sudo group is named "sudo," not wheel. Wheel is a Red Hat/BSD-ism. [17:30] if you add a user manually, they're not added [17:30] you have to gpasswd -a {user} sudo --- or add to /etc/sudoers etc [17:30] sypher: I know that [17:30] * sypher shrugs. "Just being clear." [17:31] O ok so if i just adduser it won't beable to sudo to uid unless i add it to the group sudo or place the user in the sudoer file [17:31] exactamundo [17:32] you'll get an error saying the user is not in the sudoers file [17:32] and it'll mail root (or whatever the admin email is set to) about the violation [17:32] sane defaults ftw [17:33] Got it now i see so then how is user 1 and user 2 which are in different none sudo groups have different privilages/access levels... is the file system storing the gid and uid exceptable to access the file or resource [17:34] the filesystem has attributes for storing the file owner/group [17:34] gymdude: yes. every file or directory has permissions for a specific user (the owner), a specific group (the owning group), and everyone else [17:34] gymdude: see https://en.wikipedia.org/wiki/File_system_permissions#Traditional_Unix_permissions [17:34] in fact there are a lot of attrivutes it stores [17:34] gymdude: and https://en.wikipedia.org/wiki/Modes_(Unix) [17:37] This is for HDD resource how does the os keep track of memory blocks a user or group has access to . Because you have 2 main resources HDD and memory [17:37] CAPS [17:37] Since device drivers are controlled via files , programs thats taken care of by HDD resources [17:37] along with loads of other ways :) [17:38] "Everything is a file" [17:38] down the rabbit hole - http://man7.org/linux/man-pages/man7/capabilities.7.html [17:39] GDT , paging ,...etc doesn't take into account the user or group just weather the program itself stays with in its memory allocation/ memory resources [17:39] so if one can run the program it doesn't care what user or group ran it [17:40] So what i am getting at is how can one user have permission to access memory and another user cann't access that same memory or is that even ever considered [17:40] well, the kernel manages some part, but the memory management will happen inside a program.. Hence why there are hacks like heartbleed.. bad memory management [17:41] and why rust is awesome [17:42] there are 'mitigations' in the kernel which subert this, memory address randomisation, stack protection etc [17:42] ...well what i was wondering is they any way directly to restrict particular users or groups to certain memory [17:42] (ironic as I'm building grsec kernel atm too) [17:42] it's restircted by default [17:42] Obviously indirectly thru program itself or file permissions [17:43] not sure what you mean by 'certain memory' [17:43] A user cannot access memory allocated by programs run by other users, with the obvious exception of root. [17:44] the memory manager at the kernel or user level doesn't care at a user or group level [17:44] unless it's a badly written program that reads/writes to an area of memory it shouldn't aka a hack [17:44] it only cares about if the block is marked shared , private,...etc [17:45] gymdude: a process can only access its own memory. if it tries to access another process' memory, that's a segmentation fault. [17:45] gymdude: is there something you're trying to figure out or accomplish that's leading you to all these questions? I have a feeling you're going in a particular direction, but I can't figure out what that direction is [17:45] ya got that so its more securing users and groups thru file permissions then thru what user access memory [17:46] And the memory manager only cares to keep programs/process separate so they don't violate one another [17:47] there's no real 'memory manager' as it were too, malloc and stuff sure but not in the kernel, not in that sense anyway. Programs themselves manage their memory, depending on what language you use you may have to manage it, it could be manageg for you, it might use garbage collection etc etc [17:48] joelio: there is absolutely a memory manager in the kernel, translating physical addresses to virtual ones and managing which pages are allocated to which processes [17:48] in the task_struct of the kernel there is a memory substructure it uses but thats just to check if the task running can access this memory... is sharable block ,..etc [17:48] tarpman: I mean in the sense that gymdude was describing [17:49] tarpman: aware of that, otherwise how would KSM work ;) [17:49] fs_struct is the substructure for what files the process uses , weather there locked ,..etc and the HDD file system contains the permissions/privilages for the user/groups for accessing/denying them [17:50] So permissions and privilages are all part of the HDD drive nothing more [17:50] righ [17:50] regardless of what os's for the most part [17:51] This is why physical access to a system can render the majority of security protections immediately moot. [17:51] righ [17:51] right, time to go home, laters :) [17:51] unless of course they put more into a sub structure of the task_struct for process [17:51] at some point [17:53] either way that wouldn't be worth it because you be chewing up memory at the same time as needing it stored on the HDD for permissions to be persistant over boot ups [17:54] so not really a point to put it in the task_struct for individual user or groups so much [17:55] ...That gets me to another point if you cann't get root privilages cann't you always boot a live cd and change the permission of the file you want to access without even having to mess with the passwd file or user anyway just change it to user 1 as owner instead of root on the HDD drive ... [17:56] provided you know where on the ext 4 or so you need to change to do this [17:56] yes. as sypher said, physical access lets you do pretty much anything [17:56] equivalent of sudo chown ... but directly modifying HDD bits [17:57] that sounds like a lot of effort. I'd boot a liveCD/liveUSB and use chown :P [17:57] or use passwd and reset the root password, or, or, or, ... [17:57] gymdude: I feel compelled to observe that you're going through an awful lot of effort to appear knowledgeable about disk and memory data structures, without even a basic understanding of how permissions are managed by the system itself. This seems... backwards. [17:58] indeed [17:59] ya your right i am over complicating things [17:59] gymdude: If I had a recommendation, it would be to set aside what you think you know about how these data structures function, and start at the foundations. Learn the operating system and how permissions and privileges are managed. Only then can you put the more advanced topics in the proper context. [18:00] gymdude: To be clear, I'm not trying to offend or otherwise demean. I do, however, have a number of years' experience teaching these sorts of topics, and I don't want you to trip yourself up while you're trying to learn. [18:00] there managed by the file system driver program [18:01] and the ext4 file structure [18:01] or in general the file system driver and file structure [18:02] Just different file systems store the permissions and privilages in different ways i.e registers , databases , cluster fields for fat , ntfs MFT or directory entries [18:03] just over thinking it thanks [18:07] Might want to read http://tldp.org/HOWTO/html_single/Security-HOWTO/ [18:24] And LSA secrets whas before the invention of syskey for encrypting the same either way one can obtain these with bkhive and other register scrubbing programs [18:25] But i am curious if one has bitlocker or whole HDD encryption How can one ever do password reset thru bkhive, chntpw ,...etc like programs [18:25] gymdude: Without the key, you don't. [18:29] but wait whole drive encryption or bitlocker encryption doesn't encrypt the system partition and thats where the sam file is so one should beable to password rest a user without decrypting the data paritions [18:30] So adds no additional difficulty in changing the sam or changing passwords for the user [18:30] i would think [18:31] kind of confused on this if the system files aren;t encrypted and its not at the bios level for decrypting the HDD then how is it going to provided any more security [18:32] gymdude: maybe there's a channel for discussing bitlocker and windows security, but I don't think this is it [18:33] ok last question if one did change the sam file with an encrypted drive what would happen the partition isn't being encrypted just the data so the os should boot and you should beable to change the password to use the machine except it won't decrypt your other paritions [18:34] ...so you won't get the data but you should beable to get a usable working os's [18:34] if you want a usable working OS just stick in a USB stick or something [18:35] true good point [18:35] gymdude: None of this is on topic for this channel, so we're clear. [18:35] but was curious of that [18:35] gymdude: depends entirely on which partitions you encrypt. if / and /home are on different partitions, and you encrypt /home but not /, then yes, you'd have a working system but no access to data [18:35] hola [18:35] hay algn canal de ubuntu server español ? [18:35] If he's discussing SAM files, he's not talking about Ubuntu (or any Linux) anymore. [18:35] gymdude: ... but in that case you'd also have a perfect opportunity to sneak in a rootkit or something. so IMO you want to encrypt everything, all of / [18:36] !es [18:36] En la mayoría de los canales de Ubuntu, se habla sólo en inglés. Si busca ayuda en español entre al canal #ubuntu-es; escriba " /join #ubuntu-es " (sin comillas) y presione intro. [18:36] asrockus: #ubuntu-es XD [18:36] sarnold muchas gracias ! [18:36] de nada :D [18:37] xD [18:37] but can you encrypt the system paritions as well thus the complete HDD and have the bios some how decrypt and encrypt the whole thing at boot up so its like boot up---> decrypt os system paritions ---> decrypt data partitions/others --> run the os [18:38] estoy tratando de configurar ubuntu server pero se me es muy complicado jajaja [18:38] Because thats the only true way to stop password resets or any uses of that particular installment to the person that has the key [18:38] gymdude: It doesn't decrypt it on the disk at all. Data read is decrypted in memory, data written is automatically encrypted on write. [18:38] gymdude: not that I know of. every setup I've seen, you need the bootloader and /boot (kernel and initramfs) available and not encrypted [18:38] gymdude: if you want to ensure no one has snuck a rootkit into your bootloader or kernel, you're looking at TPM and/or Secure Boot [18:38] tarpman: Newer versions of grub support an encrypted /boot. [18:39] sypher: nifty! noted, will look into that [18:39] so s/bootloader or kernel/bootloader/ above :) [18:39] but for going one level higher encrypting / that would take firmware or bios to do it [18:39] just curious if they have that [18:39] gymdude: no, encrypting / does not require firmware support [18:39] gymdude: No, it would take a bootloader, which is ... what I just said. [18:40] its definitely not need in most cases over kill just curious [18:40] It's not overkill at all. [18:40] gymdude: Where are you getting these opinions/observations? [18:40] No i meant not / but the whole HDD when i said that so MBR and partition tables encrypted [18:41] to [18:41] it's possible, but involves manual adjustments and it's easy to break it. http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/ [18:42] this is not with "secureboot" / TPM involved, though, though this may also be possible. [18:42] ya i get you but i was think more local not thru a network resource just a whole internal HDD being encrypted by itself standalone [18:42] that link isn't quiet that [18:42] gymdude: It's recommended that you create one container partition for the encrypted data, then store everything else insite that container. [18:43] Trying to just encrypt a whole disk device is a recipe for something between aggravation and disaster. [18:44] gymdude: if you're tlaking self-encrypting storage media (so, in hardware / drive / controlelr firmware), this would be something for ##hardware rather than here. [18:44] so you basically have grub unencrypted but password protected and the other paritions holding different os with data and system files or other thing completely encrypted [18:44] But your still relying on the boot loader at the top level being unencrypted [18:44] which is why I was talking about secure boot - to ensure the boot loader stays trustworthy [18:45] That's really the only good way to do it. [18:45] ... I want to know if there is away to complete encrypt that to and do the encryption / decryption of the boot loader from the bios or firmware level thus making it one layer more secure [18:45] what does secure boot do [18:45] one layer more secure? one layer more fragile, more like [18:45] gymdude: don't make me LMGTFY you. [18:46] gymdude: You really are taking this to an extreme without understanding any of the components. [18:46] gymdude: go away and read every single post on mjg59.dreamwidth.org and then come back and we can talk [18:46] gymdude: And from the tone of the responses you're getting, I'm not the only one getting a bit annoyed by the fact that you're not doing your own homework/learning. [18:46] I just wondering if manufactures ever made one not it would be useful as much more for research [18:46] gymdude: many hard drives have variants that support on-disk encryption. Most people don't trust these drives entirelly because firmware authors have a tendency to suck at their jobs and write terrible firmware, but it is an option [18:46] don't get me wrong, I love talking about this stuff [18:47] sarnold: 100% truth, there... [18:48] tarpman: pm okay? [18:48] this discusses the "secure boot" process http://www.linuxjournal.com/content/take-control-your-pc-uefi-secure-boot [18:48] sypher: yeah, I'll take the noise elsewhere. sorry. [18:51]