[00:00] eh, why hide it from the owner? [00:00] so, no, if he owns the account, he can become root and also have access.. any encryption without his knowledge smells bad to me. [00:01] Because its my source code on the machine [00:01] So, that sounds..um...fishy [00:01] that is contractually not allowed for him to clone/copy [00:01] very fishy [00:01] but I have no way of restricting that technically [00:01] if you don't trust them, don't put your source code on their machine? [00:01] then don't store it there. [00:01] JanC, I've to run software that solves a problem for the client [00:01] oerheks, I have to - to run it [00:02] I was thinking of encrypting the file system using encryptfs [00:02] You need ther source...to run it [00:02] but that does not solve the problem [00:02] the [00:02] Ussat, yes, I do need source to run it [00:03] So, you are going to make part of your clients system, unuseable.....OK I will put it bluntly.....I would find somewhere else REAL fast, because thats a shitty thing to do [00:03] I could keep keys outside the machine, and encrypt the machine - so that everytime I booted the machine, it would ask for keys from outside the system. [00:03] ut, thats just me [00:03] encryption without the knowledge or permission of the persons you're working with is a very very grey area legally [00:03] Ussat, unusable ? I just dont want the client to have the ability to copy my source? [00:03] that could get you in trouble [00:04] geosmile: then use a compiled language that you only provide binary files for [00:04] and if you need the source, to run something, then thats an a bigger problem [00:04] teward, It is a machine on which I am root, and I own the machine. What are you talking about? [00:04] > So, you are going to make part of your clients system, unuseable.....OK I will put it bluntly.....I would find somewhere else REAL fast, because thats a shitty thing to do [00:04] teward, I cant do that - its not cost effective [00:04] geosmile: then you're in the catch-22 of software [00:04] either you provide your source so your stuff works [00:04] or you don't put it on the **client**'s machine [00:04] teward, if you dont have a solution - why speak? [00:04] I propose you have bigger issues [00:04] what Ussat said [00:05] i'm proposing the same [00:05] you have larger issues to tackle [00:05] I agree [00:05] (this also sounds a lot like an XY problem) [00:05] why is a more traditional SaaS approach not possible? [00:05] Its not a trivial issue [00:05] who does contractually own the code? [00:05] ^^ that [00:05] JanC, I do [00:05] so then make sure that's stated very clearly in your contract, and if they steal it, sue them [00:05] sarnold, because there is client's data on the machine. [00:06] JanC, I won't last while I sue them - I've thought about that [00:06] So - apart from encryptfs - is there something else I can do - that secures the data on the machine? [00:06] I propose if you dont trust yuour clients, you choose better clients then [00:06] vet your clients better [00:07] build a vm with the code, and store it and its output in an archive? [00:07] Ussat, really? you want to trust your clients with your source code ? Vetting helps? [00:07] geosmile: your business premise is the problem here. The only way to secure the data **on your clients machine** is to provide non-source-code versions. If you can't do that, then you need to provide SaaS that **does not** have the requisite of being on your clients' controlled machine to begin with. If you can't do **that** then you need to rethink your approach to this entire project [00:07] your usercase might be compromised either way [00:07] THAT ^^^^ [00:07] because **contractually binding** it so that if they copy or keep your code as a lawsuit is the only way to punish the company [00:07] even non-source could be stolen... [00:07] your use case is compromised simply by what your goal is [00:08] I am REALLY cureious, what kind of business is this / [00:08] and your user base will not employ you if you require special encryption and such that is under client's controlled machines [00:08] and not your own (even managed service providers provide their own machines for them to manage if it ABSOLUTELY requires clients to put it into their environment and not allow the Client to have access to that infrastructure) [00:09] also, they seem to trust _you_ with their secret data, why can't you trust them? [00:09] ^^ that - the double edged sword. [00:09] JanC, They have checks if i steal their data, since I am on their network [00:09] JanC, I dont have a way to secure my code [00:10] if you don't have a way to secure your code, you shouldn't be putting it on client machines because **You yourself do not trust the client** [00:11] There is something thats...fishy here [00:11] heck, even as a consultant myself **all code I put onto a client's machine** is done under contracts and all Open Source anyways, if you are using something that is Closed Source you shouldn't risk it being put on the client machines. [00:11] agreed with Ussat [00:12] it's not like binaries are really more safe than code... [00:12] Ussat, if you dont understand something - of course it's fishy. Instead perhaps think about a solution - instead of a fish? [00:13] JanC, It's more painful to decompile for sure [00:13] if it's really all that valuable... [00:13] i don't see what your original 'problem' is here, you are just asking about your **solution** not the core problem you're trying to protect against [00:14] if your problem is "I have no controls to prevent others copying my code" then you shouldn't share your code [00:14] https://xyproblem.info/ <-- this is what your issue sounds like [00:14] the XY Problem [00:14] the real solution is a good contract combined with trust [00:14] ^^ that [00:14] teward, the problem is very simple - if you want to understand it. [00:14] So, youre saying youre slource must REMAIN there to solve a problem [00:15] I want to work on an AWS EC2 instance - without giving access to Amazon - Prove its impossible - or disprove with a solution. [00:15] and you don't want to enforce your contracts with legal methods [00:15] I propose your "solution" is not a good solution [00:15] without giving access to Amazon [00:15] Ya...ok sure [00:15] geosmile: whenever ${SYSTEM} is not in your own physical possession you can't control anything [00:15] thats not happening [00:15] teward, but you can, when it is in your posession [00:15] teward, that doesnt prove a thing! [00:15] anyone with physical or console access to the machine directly (Amazon) can access your system [00:16] geosmile: Rule #1 of System Security is: If anyone else has access to the machine, it's a risk [00:16] teward, sure - but when they do - they might get random bits [00:16] so if anyone OTHER than you has access to the system, you either (1) accept the risk that ANYONE with admin on the machine you're deploying to can access your code (and your CONTRACT will enforce rules about copying, etc.) [00:16] dude there FREEKING AMAZON.... [00:16] or (2) don't deploy your software [00:16] you don't have other options [00:17] you have no solution to *block* access to your *source* which **you say you must have there** [00:17] and rule 0 applies [00:17] You are trying to solve a personel issue technically, not gonna happen [00:17] the only other solution is, in your contract, forbid the copying or use of your code and audit all access attempts. and then when that's breached, sue the client [00:18] but as you said that'd not be "doable" for your AMBIGUOUS business case [00:18] in which case you have no way to protect against the issue you're trying to prevent - no legal repercussions, no reason for anyone to obey the contract. [00:18] this is a personnel / business operations problem, and not one you'll solve technically. [00:19] Thanks. Will try to solve it contractually. [00:19] to put this into another perspective let's take an active Consulting contract I have with the Lubuntu Team for adminning their infra for them. [00:20] that contract specifically states: "All materials present on the Lubuntu Team's infrastructure is the property of the Lubuntu Team. Unauthorized copying of the data to any environment is a violation of this contract and subject to legal ramifications." [00:20] so even though I have full root access to their systems to admin their stuff, and run *hosted* infra for them as well, everything on those servers is *their property* and they have contractually written in that I am not going to steal their stuff [00:21] teward: well, except for all the open source software they don't own, I'm sure? :) [00:21] JanC: well, that's in the Exceptions in that section of the contract. [00:22] I assume it's about content & maybe configurations (although it might be hard to claim copyright on those) [00:22] "Exceptions to the ownership of property are existent for any open source software provided under other licenses and not direct property of the Lubuntu Project and Team, including but not limited to: Phabricator, Discourse, Jenkins, Matterbridge" [00:22] JanC: basically, yes. [00:22] but the point was any code they wrote and uploaded for example is going to be their property [00:22] vs. the software they already deploy [00:23] i'm not at liberty to share the entire contract ;) [00:23] and I suppose all scripts you write for admin purpose are owned by them [00:23] unless the scripts are deployed open source. [00:23] and just reused by me :P [00:23] but basically, yes. Except where the scripts are already present in the Ubuntu repos, etc. [00:24] there's a LOT of exceptions written in as well, but that's the benefit of 2+ years of the contract existing ;) [00:25] best to be as clear as possible in the contract, and then trust the other side means well :) [00:25] yep :) [00:25] it's not like Lubuntu's infra is running anything proprietary either [00:26] all the core stuff they use is Ubuntu driven and Open Source [00:26] except for the VMware Tools that's installed on the hosted infra in my cluster under the contract :P [00:26] but that's not mine either ;) [00:26] the contract's pretty airtight protecting IP on both sides [00:27] and again, it's under contract - breach means legal repercussions [00:27] for either side depending where the breach happens. :P [00:27] but again, that's a business operations thing, not a technical enforcement [00:28] audit: yes. control via contract: yes. control via technical means: restricted ACL to access the machines, no other technical enforcements. [00:28] (again, per contract) ANYWAYS i digress. [00:28] *goes back to stabbing SQL code* [00:29] Thanks teward - I just need to replace that Lubuntu by "me". [00:29] no, you need a much more verbose contract [00:29] if its my property - and copying/snapshotting/... [00:30] AND given this quote from you: "I won't last while I sue them - I've thought about that" [00:30] you **need to enforce the contract with legal repercussions** [00:30] the wording in my contract won't help you [00:31] it's a consulting contract, not a SaaS or "I'm Providing Softare" contract [00:31] YOUR contract will have its own needs [00:32] teward, you are right - time to talk to a lawyer for that problem [00:32] yup [00:32] (and I keep a lawyer on retainer for this purpose LOL - all contracts NOT issued by my LLC need heavily reviewed first before I do any signatures) [00:36] that, and the Lubuntu one has some bias, I've worked with the Lubuntu team for a few years on a few things so there's a larger web of trust there :p [00:36] ANYWAYS [00:36] i need to go stab the postfix channel i need some... custom things and opinions... [00:36] thank you! [00:39] JanC: there's only like three cases where I have an SaaS or "Software provided under contract" situation, and all of those cases are 'protected' by deployment of a managed device which I own and lease to the customer under the contract, or a dedicated VM template/image/deployment that I've already built and Customer doesn't have any access to directly other than through the deployment wizard which preconfigures the deployed system [00:39] nothing to contribute here, just would like to say this has been an enjoyable backlog to read. :) [00:39] which in turn block the 'client' from direct access to the system, but again they physically have access so it *could* be someone bruteforcing but yeah. [00:39] pizzaiolo: heh it's fun to read the chaos yes? [00:40] lol yes, but more interesting to hear about your contract and contracts in general. i've personally been burned by ambiguity and lack of a contract early in my career so i learned that lesson [00:42] heheh well I'm not a lawyer [00:42] but when you have to run a business you learn stuff ;) [00:42] it's the lawyers that do most of that work for me :P [00:43] it's probably not that hard to do a good contract yourself either [00:53] JanC, if you give them a dedicated VM template - once they have the template - its still the same problem, no? [00:57] I think you want to ask teward that [00:57] but I guess there are ways to do that when there is a trusted 3rd party [00:59] geosmile: the VM is limitedAccess to the template, but again we audit the crap out of the access so anyone accessing it without it being me triggers a huge warning email and CC'd the lawyers the corresponding contract data (self-written audit code!) but that's a different set of circumstances because I don't hesitate to sue clients who break the contract. And such contracts are amended contractually for "Managed VM Appliances" [01:00] but again, everything is contract driven for controls [01:00] and USUALLY have major repercussions for clients heh [01:23] Is there a difference between `chmod 0400` and `chmod 400`? [01:24] at bash, no; in programming languages, maybe [02:09] 0400 would override suid/guid bits [02:11] $ touch test ; chmod 7777 test ; ls -l test [02:11] -rwsrwsrwt 1 sarnold sarnold 0 Jan 16 02:10 test [02:11] $ chmod 400 test ; ls -l test [02:11] -r-------- 1 sarnold sarnold 0 Jan 16 02:10 test [08:14] sarnold: in other languages a definite yes :) (400 == 0620) === ivo_cavalcante_ is now known as ivo_cavalcante === denningsrogue4 is now known as denningsrogue