On Mo
I do not think this increases security but Arno already mentioned this.
You can check various wrappers (in Debian for example) and integrate
support for smardcards etc.
But I would better to see that GUI does not implement these things,
this should be separate code.
ok, will not then. It was just a though as i was looking at truecrypt to see what features it has.
Why doesnt cryptsetup support two factor authentication?
Btw there a lot of cleaning needed in your zulucrypt code.
It is not easy to package it - and without users in distros this make no sense.
For example your hardcoded "build" script should be replaced by qmake
(or whatever Qt world prefers today).
If you look at the code, i am sure you have seen it looked "amateurish". Thats because this is my first attempt at meaningful programming and there is a lot to cover. I started with cryptsetup because i manage a bunch of encrypted volumes in files and managing them through a cli interface was annoying, i created a script to simply the task but it still involved opening a terminal and typing commands and it got really boring really fast.
That is why i started this project with two requirements, it has to work without requiring root's password(suid program) and it must work with encrypted files, of type "plain" because thats what we have mostly. It already does what i want, i am working on it further to learn more and make cryptsetup easier to use for others too.
packaging is something i was going to do next and i currently do not know anything about them, the script was a quick hack to build the package and install it while i concentrate on learning and doing other things. If packaging can not work with it, then i will change it to use qmake for everything.
Another thing is loading of libcryptsetup through dlopen(). Not
only this will not work on other architectures (think /lib64)
Can you clarify on this? it will not work because dlopen isnt present/works differently in 64 bit or because the search path in my code does not include /lib64?
but
why you are doing this at all? There are versioned symbols,
you should link the program directly to library...
(Otherwise after upgrade in future this can do really bad things.)
because this is my first attempt at meaning programming and i am creating an suid program without really comprehending a lot of what i am doing and suid program in linux are practically considered a sin, was just trying to cover my bases by being as specific as i can. I though going straight and manually picking a library will be more secure. Will go back to linking directly. Thanks for the input.
I could have statically link against the library but pclinuxos does not ship with the static library, cryptsetup only build it on request at build time and i though other distros also do not ship with the static library and this could inconvenience users and thats why i went with the shared library.
There is great potential in some GUI similar to Truecrypt one
but your code is really not ready - don't you want better spent
time with cleaning the code?
i try to clean it as much as i can. If there is anything more you can think that needs cleaning, please tell and i will do it.
While we are talking about cleaning the code, from what i know so far, "mount/umount" system calls do not add entries in "/etc/mtab" and tools like kdiskfree do not show these opened volumes if they do not have entries in mtab, manually editing the file corrupts it and that is why i use "mount/umount" cli tools through popen because they do whatever they to do add entries in mtab on mounting and unmounting volumes.
Can you think of a way i can do this completely within my program without corrupting the file? manually editing mtab will cause mount/umount command to hand and then they complain about unlocked /etc/mtab~ or something.
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
